Couple of months ago I invited you to review 10 different definitions of the term “Enterprise Architecture”. While the current leader is the definition of Gartner Group (which is one of my favorites too), it still gives a pretty high-level introduction to the term. How should the created key principles and models be structured? So that they can be efficiently communicated to support better decision making on enterprise´s change? Well, this is exactly the mission of an architecture framework, helping to focus on relevant parts of an enterprise, their properties and interrelations. These abstractions of an enterprise are further structured into so-called architecture domains. The de-facto standard framework TOGAF defines the following domains:
• Business Architecture domain,
• Information Systems domain (which consists of Data Architecture domain and Application Architecture domain),
• Technology Architecture domain.
Good definition, isn´t it? However in my practical experience I have faced a number of questions while trying to explain the term “EA” in detail and apply it in practice. Briefly, my amendment of the above definition focuses on two types of architecture elements: "services" and "information". In this blog post let me share with you the overall picture, dating back to summer 2007 and focus only on "services", while "information" will be touched in detail later.
The Business Architecture is concerned with creating of a structure of people, information, and technology in form of a process. For the Business Architecture, a reusable component may be a business process. Business architects would not, primarily, be concerned with reuse of an IT System\application, because that is the concern of the Application Architecture. Nor would the Business Architecture be concerned with the reuse of a technology (like email) because that is the concern of the Technology Architecture. So we may consider that every architecture domain implies a certain set of architecture elements the domain is responsible for. Business Architecture owns processes, org. structure, process-related KPIs. Information Architecture owns business terms, business data objects, data messages. Application Architecture focuses on business IT systems and their high-level software components, while Technology Architecture cares for basic software, hardware and telecom technologies.
Well, but how could we fit services into these domains? First of all, we should define what a service is at all.Let me put it simple: service is a contract between a consumer and a provider describing what can be consumed\is provided and with which service level. So that means that service is a contract not bounded neither to a consumer nor to a provider. Then which of architecture domains listed above should own such a contract? In my opinion neither of them caters for this need! Same service can be provided by an IT or by an organizational unit .Should this contract be a part of the Business Architecture domain or the Application Architecture domain then?
That led me to introduce Service Architecture domain and separate it from other architecture domains. That means to define Service Architecture not as an aspect as Cap Gemini´s IAF does because an aspect cannot be made responsible for a certain type of architecture artifacts, like contracts are.
The Service Architecture domain owns service contracts, their properties and their interrelationships. Capabilities, both functional and non-functional, describing in detail what can be consumed or provided is also a part of the Service Architecture domain. Business services, application services, information services, infrastructure (technology) services - all fit into this architecture domain and therefore support a sustainable management of enterprise services.
Surely companies can profit from such a consumer\provider-independent service approach:
• enables enterprises in harmonization of service portfolios without digging into details of each and every consumer and provider
• helps companies in definition of service level agreements during business process and IT outsourcing with no knowledge on consumer\provider upfront
Moreover the trend in making business internally more service-oriented (even within classic discrete or process manufacturing enterprises) concerns a company of almost every size and clearly forces the broad adoption of IT-neutral Service Architecture…
I appreciate your opinion on how services can be fit into architecture domains!
