July, 2008

Governance Challenges

Architecture Governance is a challenge in larger organisations where IT is not centralised. In my experience

in such an environment there are always business units within the organisation that will want their way with

the technologies they deploy and the way they design their solutions. Compromises are possible, though. If

its technologies and designs do not jeopardise the organisation’s IT fufure, the business unit can be

“ring-fenced”. Another option could be that only certain technologies and designs are targeted for

governance, leaving the rest flexible - once again, as long as the organisation’s future is not put at risk.

Architecture Governance

Once the future state vision for the organisation’s IT and Business (with suitable principles) is in place, it becomes necessary for day-by-day design guidance to be given to development projects. This is required on 2 levels — guidelines to be employed by the business process designers, and in turn the IT solution designers. The benefit is that the entire process and system creation and enhancement effort should comply with sound practices and design methods from the architecture, rather than each step being taken as a single event with design on an ad hoc design approach.
Architecture Governance in a large organisation is not always easy, especially if IT is not centralised.

Application Architecture

What is Application Architecture all about? Firstly, the business drivers of an application should be identified and architectural needs of the application should be derived from that. Requirements for an application should be completely and unambiguously specified. For example, requirements like “Architecture should be robust” have no meaning unless it is quantified as “Architecture should be able to provide 24×7 availability support with maximum system downtime of 5 min”. Then there are also the Technical requirements, for example scaling up, fail-over capability and many others. Database design requirements are also part of an application’s architecture.

Solution vs Application

What is the difference between a Solution and an Application? For me there is no difference, as they both exist as a result of some business requirement, they both might consist of programming code (albeit bought or custom written), they very likely need data to be kept somewhere and they both need infrastructure (hardware) to make it hum.

Chief Enterprise Architect

Let’s briefly examine the role of the “Chief Enterprise Architect”. This role, as expected, is a leadership role where the EA programme of developing, maintaining, governing and evolving the architecture, is managed by the Chief EA. The person in this role will benefit from deep experience in specific architecture domain(s) or even deep experience in business architecture and/or strategy. Architects and Enterprise architects might report to the Chief EA.

EA Team Structures

How are EA teams structured? Many smaller organisations do not even bother with teams, yet have good EA practices in place. In my experience it does help in a large organisation to have some team structure and processes in place to deal with the multitude of interactions with the IT and Business departments. Typically there will be an architect per domain, e.g. an Information architect, a Security architect, one or more Application architects, etc. These might all report to an Enterprise Architect or Chief Architect. In my organisation all architects and enterprise architects report to the Chief Technology Officer and there is no Chief Architect.

EA Personalities

Talking about roles within EA, there are opnions about the “personality types” suited to the disciplines of EA. Characteristics such as extroversion, introversion, “sensing”, intuition, thinking, feeling, judging, perceiving, directive, analytical, conceptual and behavioural have been used. I personally am very careful about putting people in boxes like these. Any opinions - which personalities will be more successful at EA?

EIA Roles

Within an Enterprise Architecture there are, as alluded to earlier, various roles such as that of the Enterprise Architect. Where the EA has an Information point of departure, IT analysts, business analysts and data analysts might focus on business processes and information requirements, creating models from a conceptual level of detail. This could be the primary focus of an agenda called “information architectures.” Application designers, integration specialists and workflow software managers might focus on the (physical) implementation aspects of information architecture, which could be seen as “application architectures.”

EIA Framework

Before exploring the Information domain of EA, here’s an interesting thought: What about approaching an EA framework from an Information point of view? One could argue that EA is all about Information, and Paul Sturlis put forward the EIA Framework (”breakdown”) as illustrated below. The purely technical aspects still have their own leg, but Applications (”Systems”) now fall within the Business Architecture leg. In addition there is focus on the Organisation, which has its own leg.

Business Architecture

As mentioned before, EA starts with the Business and typically EA work should start at the Business level of an EA Framework. Although generally IT people are less concerned with this layer (sadly!!), it is worthwhile making some statements about Business Architecture before we continue with other layers within the framework (more familiar territory…).
IT’s greatest contribution can be achieved by starting with the business strategy in order to leverage available technology and other resources. Some important items that should be included in Business Architecture are: 1) the enterprise value chain (what the organization does to deliver value to its shareholders, etc.), 2) the major business processes that are performed to deliver the value, 3) the primary business functions performed within the processes, and 4) the primary supporting application systems in place. From the applications can then follow the supporting Information and Infrastructure Architectures.