I am often asked to suggest the best approach (or solutions) for implementing enterprise architecture. The challenge with this is that people mean so many different things by it that it is hard to know what to suggest e.g.
Strategists - usually seek a strategic IT planning solution - they seek solutions that can engage with all constituencies and are focused on establishing a single source of truth. They seek the ability to integrate data from many sources (people and systems) and communicate with many people (visualisations, reports, models etc.). The challenge with this approach is that it can take a long time for the value of the knowledge base created to be visible.
Business oriented architects - usually seek solutions that manage the technology assets (costs, value, risk etc.) and enable a wide group of people to objectively participate in the management of the existing portfolios (services, applications, infrastructure, skills) and plan future investment. The risk with these approaches is undertaking each optimization activity as a stand alone or point in time exercise rather than establishing a systemic solution.
Governance oriented architects - usually seek solutions oriented at compliance with internal and external standards. They also realise that there are many roles and constituencies that need to be engaged (so technical and some not - in any area being considered). They many focus on the management of technical standards, preferred products, patterns etc. A key to the success is that the touch point processes are adapted so that governance is built into them, and feedback loops occur naturally i.e. that the approach is inclusive. The risk with this approach if it is implemented by itself is that it is seen just as barrier to change and initiative.
Framework oriented architects - seek solutions that implement the framework they have educated in or sold on. If the frameworks is oriented around investment planning and business cases based they seek business analysis and business case management for the enterprise (usually portal oriented interfaces with document production); if it is oriented around a set of reference models they seek support for the reference models and the ability to align their enterprise with the reference models; if it is oriented around a taxonomy they seek a predefined set of semantics and views; if it is oriented around a method (a set of steps) they seek a model or portal solution that steps them through the steps with wizard-like simplicity. The risk is that framework zealots focus on the frameworks for their own sake and don’t ground their efforts in terms of visible business value.
Aspect oriented architects - these people are focus on one aspect e.g. data oriented; service oriented; process oriented; object oriented; package oriented etc. and tend to see the needs as extensions to these domain e.g. oriented at data modelling; SOA; process modelling; UML modelling; modelling the capabilities of their preferred package (ERP, CRM etc.), etc.
Solutions oriented architects - often seek extended solutions architecture - what they seek are usually modelling tools for a group of architects to use to communicate principally amongst themselves - with some views created for other constituencies. They will often seek solution of engineering oriented languages and views. Experience shows that these modelling oriented approaches seldom produce sustainable value.
Value or mission oriented architects - are usually driven directly by a project or business imperatives e.g. reduce the cost of X by ...; reduce the time it takes us to do Y by ...; reduce the risks of Z by... . They probably have the best chance of concrete success as they by definition have SMART goals.
When pressed many will say they want all these things - but the solutions they select and how they go about the implementation reflect one or more these orientations. The emphasis on tools depending on how much people place weight on:
- establishing a sustainable enterprise assets (vs meetings the needs of single constituency) which involves strategies for ensuing data consistency, quality
- communicating with all key stakeholders e.g. engaging with them interactively and allow them to enquire
- integrating data from many sources (which requires support for semantics and integration mechanisms)
- modelling and presenting the various views and diagrams that have been produced (often manually) in the past.
Sunday, June 7, 2009
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment