Jadira is the home for Sousan and Chris Pheby's open source projects. These are reusable open source Java modules that provide first class solutions using the most effective current JEE technologies.

Tag Cloud
« Calendar Systems | Main | IT's Supply, Demand and Governance: EA within Governance »

Enterprise and Solution Architecture - A Pragmatic View

In the previous discussion I introduced the concept of architecture fulfilling a key governance role within the organisation, fulfilling a mediation between the supply and demand relationships. The diagram below is my attempt to communicate about the relationships between these various functions and how architecture contributes to not only technical conformance, but also addressing the alignment of IT with the direction of the organisation it serves.

If you are looking for rigorous meta-model describing detailed causation relationships and semantic relationships between activities and artifacts, don’t look here. Instead, I suggest you start with an established model such as Nick Malick’s Enterprise Business Motivation Model (EBMM) or the Zachmann Framework. The purpose of this model is communication – it provides a pragmatic description of how architecture contributes to facilitation, quality management and alignment.

The “Demand” Function is depicted by the package shown at the top of the diagram. Demand is captured and codified by Business Strategies and Business Initiatives. Strategies describe what the business wants to do in order to create value, and how it will measure and achieve it. The ways in which businesses capture strategy differ from one firm to another, but can include business plans, missions, the Balanced Scorecard, Strategy Maps, the Performance Prism and many other techniques. Strategy sets the context for change. Initiatives are framed by strategy and describe specific changes that are to be executed within the business in favour of the strategies. Initiatives are commonly expressed via a business case, and managed through to delivery as part of a project or programme. Elaboration of initiatives typically begins expressed as a series of desired changes; eventually these are expressed as requirements.

The “Supply” Function aims to fulfil demand in a manner that is traceable back to business need. The architecture discipline that operates in this area is the well-known Solution Architect role. A Solution Architect fulfils a multi-disciplinary role that brings together the various enterprise architecture disciplines in a pragmatic manner. Working in this area you find Technical Design and Integration specialists. The output of Solution Architecture is working solutions. This area is also the domain of Project Management, and typically responsibility for delivery lies between both the technical and management role. A key technique here is the use of benefits management to ensure traceability from business case to delivery, and portfolio management to regulate the continuous alignments of projects. A variety of established practices in these areas help – including PRINCE2: 2009, ITILv3 and Cranfield University’s Benefits Management Framework.

Mediating between Supply and Demand is the “Governance” Function. This is where enterprise architecture resides, together with the variety of programme and portfolio management disciplines. These functions support the responsible executives in facilitating the delivery of value from change. Enterprise Architecture is typically described in a layered view that borrows from the classic representation of Enterprise Architecture as Business, Information, Application and Technology Architecture.

Business Architecture is concerned with the alignment of business and its dynamic capabilities (principally in most organisations specifically the alignment of business and IT). It achieves this by forming a number of holistic views that enable scenario planning, impact assessment and decision making to be achieved. These views include the business processes, the organisation structure, the application portfolio and the capabilities view of the organisation.

Maintained in step with the business architecture, the Information Architecture addresses the entities of the business, their structure, meaning and canonical forms. Information Architecture also considers the disposition and placement of data, its rules and structure and constraints placed on it. It is concerned with the elaboration of a ubiquitous language that can be shared between all stakeholders, including business and architecture.

The Technology Architecture steps from the domain of What to How. It is concerned with elaboration of the organisation strategy into a set of reference architectures, patterns and guidelines. These are supported by development standards, the service catalogue underpinning capability reuse and a base architecture model that provides a conceptual reference view for the organisation’s architecture fulfilment.

All of these artifacts frame and facilitate the work of the Solutions Architect. The interaction between disciplines is supported by Vitality and Governance processes that not only ensure conformance, but also continued development of the Architecture.


PrintView Printer Friendly Version

EmailEmail Article to Friend

References (5)

References allow you to track sources for this article, as well as articles that were written in response to this article.

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>