Intersection between Enterprise Architcture, ITIL and the SOA Movement

The past few weeks I have had an ephitheny about the relationship between ITIL and Enterprise Architecture. The relationships that the Enterprise Architecture bricks describe the information needed for a configuration item (CI) inside of the CMDB. That a CI has to have a type associated with it and that type should be a brick inside of EA.

How I came about this discovery is I was trying to figure out what are the CI for our application infrastructure. It seem to me that ITIL focused on the component aspect of things inside of the production environment. This usually consisted of things like physical devices and brought-in software. But the more I thought about that, it seemed as if something was missing. Bespoke (British for custom-made) software (stuff you build yourself) didn't seem to be as well covered.

So, it seemed as if the connection between the service provided and the hardware, software used were connected through some indirect way. However accurate, it seem something was missing.

Dr. Warner Vogel, CTO of Amazon, gave a speech on Enterprise Architecture where he indicated that Amazon was really a platform where buyers and sellers get together. The largest seller using the Amazon Platform was the Amazon Store. But when you think of Amazon, you have to think of the various domains that are interconnected. One domain is the platform which does things like provides services such as item management, buyer-centric human and systemic interfaces, seller-centric human and systemic interfaces, shopping cart management, promotions, advertiser-centric human and systemic interface, etc.

But there are other domains involved in the ecosystem. Front-end providers which sell through their interfaces items in the Amazon product set. Also, you have product providers (sellers) which offer their products and services as part of the Amazon product set. Another domain is the actual buyer who has their own process of purchasing a product that may connect to any of these sellers.

The point is that there are many intersections between these domains. That became significant to me in my quest for understanding. I asked myself, "What is really happening at these intersections." The answer I got was that control was being transferred.



In this diagram, you see that there is an interdependency between these domains. In particular, there are processes inside these domains that temporarily pass control (perhaps asynchronously) to the provider domain, which in turn can pass control, etc. When I thought about this harder, I came to the conclusion that there were two views into this intersection: the Interface and Interaction.

The interaction defines the reason for the intersection between the domain. Such as Request to purchase item or inquiry of books with "Amazon" in its title. An interface, however, is the actual connection between the domains. A "request to purchase item" can be connected to a consumer via multiple interface. There might be human or systemic. Said another way: the reason for the connection from the consumer process is the same regard of the method (interface) of connecting.



It was at this moment, that I realized that the domain boundary became critically important for sanity. So, that begged the question, "What is inside of the domain and what is outside?" and "What really is a domain?"

My conclusion is that a domain is an unit of authority that accomplishes work, orchestrates that work, provides and consumes services (collection of work) to other domains and manages exceptions, situations inside its sphere of control. Interactions specifically are what connect the processes (orchestrator) to other domains.