System is a set of interacting discrete parts organised as a whole which exhibits (as the result of interaction between the parts) some emergent characteristics indispensable to achieve one or more stated purposes.
Any system-of-interest has an architecture which is a totality of fundamental concepts or properties of a system in its environment embodied in its discrete parts and relationships, and in the principles of its design and evolution. Architecture of a system-of-interest maybe accidental or intended depending on the way of constructing this system. In any case, any serious change in an enterprise-of-interest implies changing in its EA.
Enterprise is an emotive or motivational structure, bounded by a shared vision, shared values and mutual commitments for joint efforts to achieve one or more stated purposes. An enterprise is realized by an organisation which is a legal structure, bounded by rules, roles and responsibilities. Obviously, any modern enterprise together with its organisation is a socio-technical system (in which the interaction between people and technology is a dominant consideration). Also, an enterprise is a self-evolution system.
Thus Enterprise Architecture (EA) is architecture of an enterprise as a socio-technical system. (Although, it is correct, it is a useless definition for many people). The main and unique power of EA is the ability to objectively estimate effect (cost, benefits and risks) of potential internal changes. For example, what could be the effect of changes in a business unit which necessitates some modifications in some enterprise and departmental applications?
A good EA is the primary enabler for any internal transformations of different extent: project, program and strategy. For any transformation, EA is used to define and validate the future version of EA (called target architecture or blueprint). For example, a good EA can evaluate a level of implementability of a proposed strategy.
Usually, EA is described via a set of architecture viewpoints. Those architecture viewpoints define a set of model kinds which establish relationships between various artefacts: vision, mission, objectives, rules, servers, etc. Architecture viewpoints applied to a system-of-interest generates views whcih comprise some models.
Ideally those viewpoints are aligned, but in the reality it is not the case because different viewpoints are created by different people.
Because of the socio-technological nature of enterprises and their high-level of complexity, EA historically considered as two domain architectures:
- Business architecture is architecture of an enterprise considered as a social system for delivering Value (as products and/or services). Main artefacts in business-centric viewpoints are: mission, vision, products, services, directives, objectives, processes, roles, etc.
- IT-architecture is architecture of an enterprise considered as an IT-system. Main artefacts in IT-centric viewpoints are: IT tools, processes, and methodologies and associated equipment employed to collect, transform, transport and present information.
The dependency between those architectures is, in theory, very straightforward. The business architecture defines the IT-architecture. But, in practice, very often, the IT-architecture evolves much slower than the business architecture, thus there is always a gap or misalignment between them.
To avoid this gap, it is necessary:
- version all the artefacts during their lifecycle;
- evlove artefacts to become digital, externalised, virtual and components of clouds;
- model explicitly all relationships between artefacts;
- make all models machine-executable, and
- be able to convert models from one view to models in another view.
Thanks,
AS
Posts
