In couple of previous posts I have touched already “Why Enterprise Architecture Management?” and “What is Enterprise Architecture Management about?”. Yet the question what EAM has to do with typical change (in fact project or investment management) and operational processes of a company seems to be often still unclear for diverse stakeholders in an enterprise. You may encounter a perception of EAM as a portfolio management, like which processes and applications are under operation, or you may come across an EAM initiative as a part of SDLC which sole purpose is provisioning of project start architectures. Moreover the confusion increases thanks to a couple of vendors claiming that demand management and IT portfolio analysis constitute EAM. If you would compare understanding of EAM by Gartner & Forrester you would easily notice that they have different perception too!
So what is the reason for such a diversity of understanding and application of Enterprise Architecture Management? In my humble opinion, the reason is an enterprise itself. Modern enterprises are complex, multi-faceted, moreover constantly changing organizations run by people. Enterprise architecture is about an enterprise. Certainly architecture can be segmented into enterprise, domain and solution levels; however the general perception of EAM is still on the enterprise level. On such a broad level one would encounter people with different skills and background tending to keep EAM as a management discipline within their comfort zone and thus introducing discrepancy. So that is how we end up sometime in multiple interpretations and implementations of EAM within the same organization.
In my opinion Enterprise Architecture should support Business & IT Management by aligning operations with strategy.
In that function enterprise architecture supports Business & IT Planning, Business & IT Optimization, Business & IT Operations as well as Business & IT Governance.
However what does “supports” mean? EAM does not execute planning or optimization or operation or governance, does it? Enterprise architects do not own operational processes or applications; neither enterprise architects work out business objectives and strategies to achieve them; nor enterprise architects manage operational projects transforming e.g. an organization. Instead architects contribute to ongoing governance and the steps transforming vision into reality by providing insight (i.e. appropriate deliverables) into:
- ongoing operations ( architecture of assets: processes, people, technologies );
- future operations based on impacts of evaluated strategies on ongoing operations;
- plans and projects transforming ongoing operations into their future state.
I would not argue that the primarily responsibility of architects is evaluation of future plans and their corresponding update based on constantly changing current state and impacting strategies. Nevertheless architects cannot ignore the current state (owned by operations) and progress of ongoing transformational projects (owned by project management) because both clearly impact on the future plans. Otherwise architecture management would produce just a “spherical horse in vacuum” (J that means castles in the air).
Given such a definition of EAM capability where would you position it among enterprise capabilities? In my opinion EAM belongs to enterprise strategic planning, which should run under supervision of CSO – chief strategy officer or any other top manager carrying out this role. In such a position EAM would be able to access ongoing business operations, governance bodies as well as project portfolio management and supply them with the above mentioned insights.
However, frankly speaking, how often did you come across an organization where holistic enterprise architecture management was positioned that high and supported the company strategically? A bit of architecture is often done by units themselves, on a project basis and just to accomplish operational or tactical objectives. For example, at one company business process architecture including low-level operational processes has been documented in its current (partly) and future states in order to support a global roll-out of a single ERP platform. That transformational initiative neither touched areas which were out of scope of the roll-out (“not my business!”) nor produced any sustainable architectural deliverables to support consequent optimizations (“not my business” again!). Generally speaking, long-term efficiency for business units struggling to meet their annual targets is of no priority comparing to their short-term operational efficiency. Yet IT-driven architecture management (and sometimes even with enterprise scope!) have succeeded much more frequently. Why? IT as a shared business unit serving a whole enterprise has to cope with constant operational, tactical and strategic changes and at the same time has to keep their operations stable. What I mean is that per se IT unit has to have longer term focus. Drawback? IT-driven architecture management pays the primarily attention to IT-relevant details: all what has no direct relationship to IT, its strategy, optimization, operation and governance is ignored (“not my business” again!).
If we would take the intention of EAM described above and limit to IT unit only, how would it fit into capabilities of IT unit then? Let me try to depict this using the following IT capabilities map created by Jeff Scott.
No wonder EAM capability belongs to IT Strategy and not to Solution Development (Application Development at some organizations) or Solution Operations (often combined with basic Service Management under IT Ops). In that way at least within IT unit EAM is positioned then properly.
However what should be a primary focus for an EAM practice just embarking on architecture management? Let it define strategies or master application plans or develop a metamodel describing the whole enterprise and its partners? With high probability such immature companies will end up with architects creating castles in the air. Or let them document operational IT assets – processes, people and technology? In such a case who is interested in just another often not up-to-date drawing? And in a couple of years or due to another crisis the capability (often initially just one-man-show) will be wiped out. So how should architects demonstrate their value especially in such less mature companies? Future plans on a whiteboard or in Visio have no value themselves, don´t they? Architects can create added value indirectly only and the best practice turned to be a direct involvement of architects to support ongoing transformational projects.
Taking into account the initial limited access to and low level of sponsorship for broader knowledge about the business of an enterprise, architects can still create noticeable value by supporting optimization in Application Consolidation and Integration, Technology Standardization and Replacement, Solution Extension and Modularization projects. Following Architecture Development Method (TOGAF ADM) architects will provide insight into baseline and target states of the architecture, helping to evaluate potential alternatives and identifying waivers. Project by project architects, whose focus is not limited by a single project, will help to establish a sustainable and repeatable architecture-driven solution development, thus minimizing time to market, reducing cost of acquisition and increasing business and functional fit of final results.
Certainly, just established EAM can be alternatively focused on supporting other IT capabilities, e.g. by providing better insight into alignment of demands with strategic IT plans (IT Planning) or internal ITSM processes (IT Operations) or budgeting & spending (IT Governance) or informational risk management (IT Governance). Sure, near term objectives for just born EAM practice are defined by its sponsors, either from business or IT top management. Dance with the one that brung you…
So if you would approach your top management with a proposal to establish an EAM practice, what would you pitch as the primary capability for architects to focus on? Share your opinions, please!
