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.
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.
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.
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.
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?
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.”
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.
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.
What is the role of the Enterprise Architect? The enterprise architect must map, define and standardize technology, information and business processes to facilitate the bridging of the gap between business and IT. This means that the architect must have both a macro and micro view: He must understand the business strategy and translate this into an architectural approach (macro view), but he must also be able to work with individual projects (micro view) and deliver very concrete guidance to these projects that focuses on the successful delivery of the individual project within the macro view. The enterprise architect transforms tech-speak into the language of business solutions, and he knows what technology is needed to enable business strategy.
Even the views taken of an IT Solution (i.e. a “System”) can benefit from the use of an EA Framework. A solution also has its business, information (data), application and infrastructure aspects that together make up a System. The following diagram illustrates this concept, using the example EA framework on my earlier post.