Recently I had a discussion with a senior IT leader of a company on restarting the Enterprise Architecture (EA) practice. He asked me in a very frustrating tone – why is an EA discipline needed for his company? Sadly EA today is often the practice of reviewing magazines,product catalogues, attending conferences, joining EA LinkedIn groups, and documenting technical details (on server farms, databases, IP addresses, etc.) and less about responding to business needs. Most companies are not able to define what EA is and many IT leaders are confused on how to make the EA practice effective. In this backdrop, this article touches 2 key aspects:
- The expectations from the Enterprise Architects to be effective
- The expectations from the IT and Business leaders to help the EA discipline succeed
Let us start by looking at some of the situations where EA is needed.
- EA originated to address two problems: system complexity— organizations were spending lot of money in building IT systems; and poor business alignment – organizations were finding it challenging to maintain IT systems aligned with business need. These 2 challenges are relevant even today. Hence if any company wants to address these 2 problems, then an EA is needed.
- EA deals with transitioning to the enterprise-wide future state architecture. But even if the stakeholders group (and their concerns, viewpoints and views) is specific to a line of business (LoB) or geographic area, EA might be needed if the impact is significant or transformational.
- EA is about pursuing the optimal solution at a given point in time quickly by balancing trade-offs. EA is not finding the best solution by taking months of effort. But EA can use road maps to capture the progression to the “best” solution incrementally and iteratively.
- EA is finding solutions that are cross functional. If the problem domain encompasses organizational design, business processes, data/information, product vendor roadmap, project-portfolio management, IT management (value, complexity, technical debt, risk management,) etc, then EA is the most appropriate vehicle for realizing these solutions.
- EA is not always implementing new or disrupting solutions. EA is even applicable on initiatives to harness existing investment with optimization, service improvement, or even system retirement. Again EA is about reducing complexity and aligning with the business need in the entire “Plan-Build-Operate” IT value chain.
Once an environment conducive to EA is created, what do Enterprise Architects do? Enterprise Architects primarily manage technology strategy and its implementation in relation to the business goals. What does this “manage” mean? It is more than drawing boxes and arrows or writing code. Enterprise Architects deliver roadmap(s) and ensure that the solution instantiations follow the roadmap guidelines. A roadmap is basically a ordered sequence of architecture initiatives required to enable the transition from the baseline/current state to the future state in a time bound, iterative, and incremental manner. A roadmap typically includes 4 sections:
- the current state Solution-Business Capability (SBC) matrix,
- the future state SBC matrix needed to execute the proposed business goals. This includes key use cases, scenarios, requirements of various stakeholder groups (functional and non-functional requirements),
- the gaps between the current and future states,
- the Reference Architectures (RA) that provide technical guidelines to address the gaps in moving to the future state from the current state. The RA should expose the structure of the system (the “what” aspects) and not much of the implementation details (the “how” elements).
Are these 4 sections sufficient for a developer to start his work? Probably not. Architecture, design and coding have a defined boundary. Aspects such as security, data flow, integration details, etc. are specific to every deployment and should be covered during the design phase of the SDLC based on the RA. But these 4 “just enough architecture” artifacts should be good enough for collaborating with the business in an unambiguous way and kick start the SDLC activities. The business doesn’t (and shouldn’t) care if the integration is based on Point-To-Point or ESB. Getting the business to approve the SSO strategy (SAML vs OAuth) is unnecessary and time consuming. Unfortunately today, most EA practices don’t even have these 4 artifacts and instead spend time on technical details which makes no sense for the business. Please remember, the main customer of EA is the business.
But there are many situations when the case for EA or their main deliverable (i.e. roadmaps) is diminished or even non-existent. Hence before starting the EA practice (and churning out artifacts), ensure that below situations are addressed so that the EA discipline is positioned for success and the deliverables are put into good use.
- If the stakeholders (Business and IT) don’t have a vision on the future target state, the EA function might not be effective. Enterprise Architects can however collaborate with the senior management in defining the target vision, but EAs typically don’t create the vision; EAs deliver the vision.
- EA is not purely an IT endeavor per-se. EA demands close relationship between business functions and IT for robust enablement of solutions and systems. Hence Enterprise Architects need to have the right access to senior management – both IT and business. If there are multiple hierarchal levels between Enterprise Architects and senior management, then the performance of the EA practice is hampered with red tape, bureaucracy, and inefficiency.
- If the risk of implementing the technological change is low or if the solution implementation is straight forward, then EA function might not be needed. It would be like using a sledgehammer to crack a peanut.
- EA is moving to the future state – progressively and proactively. Just analyzing and documenting the current AS-IS state with no immediate intention of transitioning to the future state is a complete waste of time.
- EA is about responding effectively to business need with effective communication. Frameworks (such as TOGAF, FEAF, and Zachman) facilitate effective stakeholder communication including Business-IT alignment. If these frameworks cannot be used to communicate the future state comprehensively, their utility is little served.
Today EA is no longer a WANT for companies; it is a NEED for companies who want to reduce system complexity and serve the business better. Although modern tools and platforms have simplified the task of programming, they have moved the complexity upfront in the SDLC; demanding solid architecture for critical use cases, scenarios and requirements. Also it is not the size of the company that determines the need for the EA discipline, but how the companies want to leverage technology for their business needs. When EA works well, it is a great tool in integrating Strategic planning, Portfolio-project management and Service management. But EA can also be a huge drain on company’s resources if it is not functioning well. Finally EA is not the end; it is the means to the end. The ultimate outcome of the EA is a solid working software (provided by IT) that relies on quality data (provided by business).
Thank you very much for your time. For a no-obligation and a no-nonsense discussion on Enterprise Architecture, I am available at [email protected]
Let me know your feedback and thoughts, and feel free to share this article in your network if this is helpful.
Regards and thank you!
Prashanth Southekal, PhD, PMP
References
- Bloomberg, Jason, “Is Enterprise Architecture Completely Broken?”, http://www.forbes.com/sites/jasonbloomberg/2014/07/11/is-enterprise-architecture-completely-broken/#1039cc12f30c, Jul 2014
- Walker, Mike, “A Day in the life of an Enterprise Architect”, https://msdn.microsoft.com/en-us/library/bb945098.aspx, Jul, 2007
- Kabai, Imre, “8 Reasons Enterprise Architecture Programs Fail”, http://www.informationweek.com/it-leadership/8-reasons-enterprise-architecture-programs-fail/d/d-id/1109248?, Mar, 2013
