Profile picture for user koiv

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.

EA overall picture with focus on services

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.

EA: Service Architecture

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!

by Ivo Velitchkov
Posted on Tue, 01/05/2010 - 15:30


The service concept is widely applicable because it implies "black-box" relations so the external environment is concerned about the value, not the means (internal structure and mechanisms). The encapsulation (=separation of concerns+modularity+loose coupling) principle of services is so appealing because of it ubiquity and potential agility. In the context of EA, services are rather gear-wheels between domains that a domain itself. But then when it makes sense (e.g. ESR) it can be treated as a separate domain like you propose.

Hare's a simple model of my view of services in the EA context, showing the main relations (some of the them, like Business Service <-> Application Service, are not shown while IT prrocess which is just a business process is shown seperately to support some ideas for Business-IT alignment though the service concept again):





by Konstantin Ivanov Author
Posted on Wed, 01/06/2010 - 22:38


Re: your metamodel - could a client consume Application Service or Technology Service (TOGAF: Platform Service) directly? Looks like the metamodel implies that the client is forced to consume only those business services which are realized thru business processes? Would it be possible that same SLA is provided by one provider using just a set of manual actions while another provider completely automate it,  that means the same set of actions become a part of application logic exposed in form of application service? Putting it from another point of view: is not it a business process which plays the "client" role and consumes IT service?

As we are digging in depths of metamodel representing a service architecture, then I personally like MODAF 1.2 rev3. It states that any ResourceType can provide a Service with a certain ServiceLevel in a certain Environment, while any ResourceType can require\demand a Service with specified ServiceLevel in a certain Environment. IMHO such consumer\provider neutral approach (as you called it a "black-box") fiits perfectly as in network-based interoperability of Defense&Security industry as in civil outsourcing. No process implied...


by Ivo Velitchkov
Posted on Wed, 01/06/2010 - 23:53

In reply to by Frank Weyand

Yes, the Client, or rather the client process, can consume directly Application Service. This is omitted from them model but it's shown for the Business Service Provider, the principle is the same. Saying "the client consumes directly the application service" includes the process already as "consumes" is behavioural pattern. So, it  is a matter of utility - if you don't need it, throw it out. As we all know, "All processes are wrong" :)

Thanks for pointing me out MODAF 1.2. I'll have a look.







Featured achievement

Say hello to the ARIS Community! Personalize your community experience by following forums or tags, liking a post or uploading a profile picture.
Recent Unlocks
  • SS
  • MZ
  • Profile picture for user kbiront
  • Profile picture for user Tony Iliev
  • Profile picture for user amandeep.7.singh
  • PacMan


icon-arrow-down icon-arrow-cerulean-left icon-arrow-cerulean-right icon-arrow-down icon-arrow-left icon-arrow-right icon-arrow icon-back icon-close icon-comments icon-correct-answer icon-tick icon-download icon-facebook icon-flag icon-google-plus icon-hamburger icon-in icon-info icon-instagram icon-login-true icon-login icon-mail-notification icon-mail icon-mortarboard icon-newsletter icon-notification icon-pinterest icon-plus icon-rss icon-search icon-share icon-shield icon-snapchat icon-star icon-tutorials icon-twitter icon-universities icon-videos icon-views icon-whatsapp icon-xing icon-youtube icon-jobs icon-heart icon-heart2 aris-express bpm-glossary help-intro help-design Process_Mining_Icon help-publishing help-administration help-dashboarding help-archive help-risk icon-knowledge icon-question icon-events icon-message icon-more icon-pencil forum-icon icon-lock