Fundamentally, viewing systems as an organized set of components and their relationships to each other yields the kind of ease and clarity of understanding that blueprints in the construction world provide.  However, having experienced these benefits, have we jumped too far into the business realm by applying “architecture” to everything outside of the technological aspect of the enterprise?  Does the business really care about its “architecture”?

The term “Enterprise Architecture” (EA) was coined by IT to highlight the comprehensive “architecture” of systems that included processes, software code, data storage and the physical hardware the systems ran on.  The first iterations of EA placed the business process model into the Process Architecture bucket.  However, as IT began to incorporate the entire enterprise into EA, there was a void in the EA model - business strategy, goals, objectives, metrics, drivers, business partners, etc. had no representation.  Thus began the transition from Process Architecture to Business Architecture.  While terminology should not be a major roadblock, there are some overly technical, IT-centric connotations that business leaders associate with the word “architecture.”  As IT tries to secure support from the business for infrastructure, Enterprise Architecture initiatives, and shifts into Service-Oriented Architecture, the business is still looking for business results.

Over the past six years, IT has been trying to utilize Enterprise Architecture to help in planning, impact analysis and IT portfolio streamlining efforts.  Formal EA departments have been added; yet according to Gartner, an estimated 40% of EA programs fail[M1] .  The business is footing the bill for this newest enabling technique, yet seeing little benefit to the bottom line.  Without a great track record of what “architecture” has done, it may be a mistake to ask the business to focus on Business Architecture.

The need for a terminology change may not be as important as the need for IT leaders to put aside their talk of tools, methods and architecture and focus more on how businesses assess markets, develop strategies, set goals, plan changes, and perform processes.  They need to see Enterprise Architects as pragmatic thinkers who put on their business hats as easily as their techie hats.  Case in point:  an insurance organization was working on a major documentation and assessment of their claims processing flow.  The current process allowed some claims to be received, yet assigned no claim number.  No one in the discussions focused on how critical an omission this was.  It was assumed that this omission was acceptable since employees had not heard of many complaints.  Few had considered the frustration of customers/insureds trying to get a status on their claim and hearing from the company that no claim had been received.  Internally, the business had no accurate count of the total claims in process because these claims were not yet included in the inventory.

After some discussion and quick whiteboarding, the process was redesigned on paper and a major improvement was in the pipeline.  No talk of architecture took place; the focus was not on systems changes – simply, an Enterprise Architect was putting on the hat of a business person and helping to think of process changes that could lead to business AND customer benefits.

If IT departments want to truly add more value to the business, it’s time to cut out the jargon and technical focus and truly act and talk like business owners and leaders.  It’s time to quit speaking in terms of technologies like SOA, architecture, BPM, and TOGAF.  If IT is indeed helping the business document and improve their processes, let’s stick to that term – process improvement – not Business Architecture re-engineering.  Not only communicate in business terms, but learn to think like the business leaders are thinking. Help them first by understanding their processes and next by helping them reorganize some of these processes for greater value to the customer.  Then, without the jargon, if system changes are needed, help them form some conclusions on how the systems portfolio can most effectively be enhanced.  Lastly, deliver.  But that’s a subject for a longer conversation.

About the Author: David Wiltz

David Wiltz has a Bachelor of Journalism degree from University of Texas, Austin.  He has written numerous articles for newsletters and newspapers including the Dallas Morning News. Currently a consultant with SIBRIDGE Consulting, David has more than 25 years of experience in IT in the roles of Manager, Application Architect, Enterprise Architect, Business Analyst, Mentor and Developer.  His major consulting focus is helping companies more effectively utilize Enterprise Architecture concepts and deliverables for operational improvement, cost savings and strategic enablement.  With this focus, a major percentage of engagements involve process improvement and/or re-engineering and mapping IT systems to business processes.  David also assists clients with improving their systems development processes, especially the up front steps of taking business strategy and objectives and transforming those into projects, requirements and architectural solutions.