Preamble
The often mentioned distinction between problem and solution levels may make sense from an analyst’s particular point of view, whether business or system. But blending problems and solutions independently of their nature becomes a serious over simplification for enterprise architects considering that one of their prime responsibility is to keep apart business problems from IT solutions.
That issue is relevant from engineering as well as business perspective.
Engineering View: Problem Levels & Architecture Layers
As long as computers are used to solve problems the only concern is to find the best solution, and the only architecture of concern is software’s.
But enterprise architects have to deal with systems, not computers, namely how to best serve business objectives with corporate resources, across business units and along business cycles. For that purpose resources (financial, human, technical) and their use are to be layered according to the nature of problems and solutions: business processes (enterprise), supporting functionalities (systems), and technologies (platforms).
From an engineering perspective, the intended congruence between problems levels and architecture layers can be illustrated with the OMG’s model driven architecture (MDA) framework:
- Computation independent models (CIMs) deal with business processes solutions, to be translated into functional problems for supporting systems.
- Platform independent models (PIMs) deal with functional solutions, to be translated into technical problems for supporting platforms.
- Platform specific models (PSMs) deal with technical solutions, to be implemented as code.
Along that understanding, architectures can be seen as solutions, and the primary responsibility of enterprise architects is to see that problems/solutions brace remain in their respective swim-lanes.
Business View: Business Value & Enterprise Assets
Whereas the engineering perspective may appear technical or specific to a model based approach, the same issue is all the more significant when expressed with regard to business concerns and corporate governance. In that case the critical distinction is between business value and assets:
- Business value: Problems are set by business opportunities, and solutions by processes and applications. The critical factor is reactivity and time-to-market.
- Assets: Problems are set by business objectives and strategy, and solutions are to be supported by organization and systems capabilities. The critical factor is reuse and ROI.
If opportunities are to be seized and operations managed on the fly yet tally with strategic decisions, respective problems and solutions should be kept apart. Juggling with their dynamic alignment is at the core of enterprise architects’ job description.
Enterprise Architects & Governance
Engineering and business perspectives are not to be seen as the terms of an alternative to be picked by enterprise architects. As a matter of fact they must be crossed and governance policies selected depending on the point of view:
- Looking at EA from an engineering perspective, the business one will focus on systems governance and assets management as epitomized by model based systems engineering schemes.
- Looking at EA from a business perspective, the engineering one will focus on lean and just-in-time solutions, as epitomized by agile development models.
As far as governance of large and complex corporate entities, supposedly EA’s primary target, must deal with tactical, operational, and strategic concerns, the nexus between business and engineering perspectives is where enterprise architects are to stand.
- Where to Begin with EA
- How to choose Frameworks & Methods
- EA Frameworks: Non Negotiable Features
- Thread: Enterprise Architecture
- Models, Architectures, Perspectives (MAPs)
- Architecture Capabilities
- Capabilities vs Processes
- Enterprise Architectures & Separation of Concerns
- From Processes to Services
- EA & MDA
- EA Documentation: Taking Words for Systems
- Alignment: from Entropy to Abstraction
- Models as Parachutes