Aggregated enterprise architecture wisdom
Check out this new whitepaper from the Open Group in the area of Business Architecture. What are your thoughts on the latest edition in their World-Class EA Series? Does it get The Open Group or TOGAF closer and deeper into…
A few years ago I commented [in Beware the New Silos, ref 1 below] that in a complicated world we cope by specialization – and across the industry in general and in individual enterprises specifically we have created silos of our primary disciplines. The widely used frameworks and methods illustrate that common practice of discipline centricity. We don’t have to look too far for examples such as Enterprise Architecture (TOGAF), Governance (Cobit), SOA (separately by OASIS, OMG, Open Group), Agile methods (many and various), Business Process Management (BPM) and IT Service Management (ITIL). All of these disciplines, whether de jure or de facto standards, are all very narrowly focused with minimal treatment of how the disciplines might work together.
A good example is how Agile methods are tightly focused on application development and architecture is assumed to be an integral part of the Agile delivery project. Yet the reality in all enterprises is that significant aspects of architecture must be consistent at the domain or enterprise level. Another good example is how the three standards bodies OASIS, OMG and the Open Group were so divergent in their treatment of SOA, they commissioned a report [ref 2 below] to explain how these inherently duplicating standards and specifications relate to each other.
The level of adoption by enterprises or service providers of all these and similar practice frameworks and standards is of course highly variable. However it must be said that the very existence of the discipline based materials will frequently have some considerable influence on how enterprises organize themselves.
The thinking IT or business professional might also like to question just how up to date these frameworks are, and how they support today’s business goals, which for most of us have changed dramatically over the past few years. We might also speculate whether the education and certification ecosystems that feed off some discipline based frameworks may discourage rapid evolution. A good example is how TOGAF maintains the core architecture style as application centric and treats SOA as a style extension. This is really quite extraordinary because by now everyone knows and many accept the digital business is going to be inherently service oriented. In practice of course the TOGAF specifications are so extensive that making fundamental changes may be very difficult, but it demonstrates neatly how legacy capabilities become “part of the furniture”, not just in frameworks but also in delivered systems and services.
In effect what we did was to establish a service and solution delivery value chain that commences with the raw customer demand and finishes with the delivery and integration of some useful business capability, but crucially with a much improved balance between immediate solution needs and longer term strategic goals. And it’s this balance that many enterprises find extremely difficult to achieve.
The core problem is that disciplines are vertically integrated; set up to optimize the discipline at varying levels of abstraction. In contrast the value chain approach optimizes across disciplines in pursuit of overall value chain outcomes. And this is only achieved by value chain activities that encourage effective collaborations between multiple capabilities and disciplines.
In the beginning we (Everware-CBDI) had a framework – Service Architecture & Engineering (SAE). The name makes it clear this is a forward engineering approach, and whilst it was very strongly business driven, it would be fair to say that the business modeling components were less well worked than the architecture, design and delivery. And as described we have very naturally, as part of the process of supporting large enterprise initiatives, expanded the framework capabilities and embraced an inherently Agile approach.
The principles underlying the framework now include:
– business capability based modularity
– pervasive service architecture
– continuous modernization
– service evolution not (one time) delivery
– model driven architecture and development
– everything is inherently agile – iterative, evolving, and narrowly focused on specific business capability delivery.
So to answer my own question, we clearly need a new framework. But it’s a very different practice framework to the ones that we are are accustomed to.
In our natural evolutionary process we recognized that the original (SAE) framework was merely one component of a much broader body of knowledge and practices. The new framework is goal driven, not discipline driven and incorporates the entire value chain of capabilities. But the capabilities are not standalone, they are effectively services that are executed in a way that supports the overall business goals of the enterprise, domain or program. We refer to this as Service Oriented Application Modernization (SOAM).
Interestingly this is not a monolithic framework. It’s vital to treat the framework as a set of capabilities with defined services and dependencies. Some might say, “eating our own dog food”. In this way we don’t make the same mistake as legacy frameworks such as TOGAF, that are very difficult to keep current.
Finally what happens to the existing discipline based frameworks and standards? Of course they can be used in conjunction with the SOAM framework. But we do need to be careful not to just inherit monolithic capabilities. Increasingly we find it necessary to do this very selectively in order to use capabilities that fit and support the value chain. Perhaps in time the various disciplines will recognize the monolithic nature of their practices, and decompose and modernize into more goal oriented components. Meanwhile, in SOAM we have demonstrated that it is possible to reinvent the wheel.
Some SOAM Components:
Agile Service Factory
Agile Modernization
Conceptual (Agile) Business Modeling
SOA Reference Framework
Ref 1: Beware the New Silos
A few years ago I commented [in Beware the New Silos, ref 1 below] that in a complicated world we cope by specialization – and across the industry in general and in individual enterprises specifically we have created silos of our primary disciplines. The widely used frameworks and methods illustrate that common practice of discipline centricity. We don’t have to look too far for examples such as Enterprise Architecture (TOGAF), Governance (Cobit), SOA (separately by OASIS, OMG, Open Group), Agile methods (many and various), Business Process Management (BPM) and IT Service Management (ITIL). All of these disciplines, whether de jure or de facto standards, are all very narrowly focused with minimal treatment of how the disciplines might work together.
A good example is how Agile methods are tightly focused on application development and architecture is assumed to be an integral part of the Agile delivery project. Yet the reality in all enterprises is that significant aspects of architecture must be consistent at the domain or enterprise level. Another good example is how the three standards bodies OASIS, OMG and the Open Group were so divergent in their treatment of SOA, they commissioned a report [ref 2 below] to explain how these inherently duplicating standards and specifications relate to each other.
The level of adoption by enterprises or service providers of all these and similar practice frameworks and standards is of course highly variable. However it must be said that the very existence of the discipline based materials will frequently have some considerable influence on how enterprises organize themselves.
The thinking IT or business professional might also like to question just how up to date these frameworks are, and how they support today’s business goals, which for most of us have changed dramatically over the past few years. We might also speculate whether the education and certification ecosystems that feed off some discipline based frameworks may discourage rapid evolution. A good example is how TOGAF maintains the core architecture style as application centric and treats SOA as a style extension. This is really quite extraordinary because by now everyone knows and many accept the digital business is going to be inherently service oriented. In practice of course the TOGAF specifications are so extensive that making fundamental changes may be very difficult, but it demonstrates neatly how legacy capabilities become “part of the furniture”, not just in frameworks but also in delivered systems and services.
In effect what we did was to establish a service and solution delivery value chain that commences with the raw customer demand and finishes with the delivery and integration of some useful business capability, but crucially with a much improved balance between immediate solution needs and longer term strategic goals. And it’s this balance that many enterprises find extremely difficult to achieve.
The core problem is that disciplines are vertically integrated; set up to optimize the discipline at varying levels of abstraction. In contrast the value chain approach optimizes across disciplines in pursuit of overall value chain outcomes. And this is only achieved by value chain activities that encourage effective collaborations between multiple capabilities and disciplines.
In the beginning we (Everware-CBDI) had a framework – Service Architecture & Engineering (SAE). The name makes it clear this is a forward engineering approach, and whilst it was very strongly business driven, it would be fair to say that the business modeling components were less well worked than the architecture, design and delivery. And as described we have very naturally, as part of the process of supporting large enterprise initiatives, expanded the framework capabilities and embraced an inherently Agile approach.
The principles underlying the framework now include:
– business capability based modularity
– pervasive service architecture
– continuous modernization
– service evolution not (one time) delivery
– model driven architecture and development
– everything is inherently agile – iterative, evolving, and narrowly focused on specific business capability delivery.
So to answer my own question, we clearly need a new framework. But it’s a very different practice framework to the ones that we are are accustomed to.
In our natural evolutionary process we recognized that the original (SAE) framework was merely one component of a much broader body of knowledge and practices. The new framework is goal driven, not discipline driven and incorporates the entire value chain of capabilities. But the capabilities are not standalone, they are effectively services that are executed in a way that supports the overall business goals of the enterprise, domain or program. We refer to this as Service Oriented Application Modernization (SOAM).
Interestingly this is not a monolithic framework. It’s vital to treat the framework as a set of capabilities with defined services and dependencies. Some might say, “eating our own dog food”. In this way we don’t make the same mistake as legacy frameworks such as TOGAF, that are very difficult to keep current.
Finally what happens to the existing discipline based frameworks and standards? Of course they can be used in conjunction with the SOAM framework. But we do need to be careful not to just inherit monolithic capabilities. Increasingly we find it necessary to do this very selectively in order to use capabilities that fit and support the value chain. Perhaps in time the various disciplines will recognize the monolithic nature of their practices, and decompose and modernize into more goal oriented components. Meanwhile, in SOAM we have demonstrated that it is possible to reinvent the wheel.
Some SOAM Components:
Agile Service Factory
Agile Modernization
Conceptual (Agile) Business Modeling
SOA Reference Framework
Ref 1: Beware the New Silos
By Jim Hietala, VP, Security, The Open Group During our upcoming event May 12-14, The Open Group Summit 2014 Amsterdam – Enabling Boundaryless Information Flow™ – one of the discussions will be around risk management and the development of open … Continue reading →
By The Open Group The Open Group’s upcoming Amsterdam Summit in May will feature a full day on May 14 dedicated to ArchiMate®, an open and independent modeling language for Enterprise Architecture, supported by tools that allow Enterprise Architects to … Continue reading →
I made an interesting mistake, today… one that comes up from time to time. I used a business term in one way, and some members of my audience understood what I meant, while others did not. In this case, the word was “core”. The word has two different definitions. Unfortunately, the definitions are quite different, at least in an Enterprise Architecture context.
The dictionary definition of “core” reflects the problem. Bing dictionary defines “core” as the “central” or “most important” part of something. Notice the word “or.” Either meaning can be intended.
This goes to an old idea of putting the most important part of something in the middle. In ancient kingdoms, the capital city was often very centrally located, usually near a convenient transportation route (like a river) that offered quick access to all parts of the kingdom (within reason). So, the word core can mean “most important” or it can mean “in the middle.” In the past, those two meanings were synonymous.
But in business, the thing “in the center” is not the most important thing. Porter illustrates this with his (now famous) value chain model:
Porter’s Value Chain. Image source.
What is the most important part of that model? It’s the bottom-half, illustrated as the “primary activities” or value chain. Porter is smart enough to avoid the word “core” because it has the connotation of “in the center” when he wanted to illustrate that value chains are not “in the center.” They traverse “end-to-end”.
Porter seems to be somewhat alone in avoiding the term “core.” Many business books and resources use the term “core” when referring to the primary activities. There are countless illustrations, if you bing for images with the search phrase “business core”, where you are looking either at a set of service offerings or a value chain. The following diagram is a business architecture reference model for the hospitality industry. The name of this model: Core Business Domains and Processes.
Core Business Domains and Processes – Hospitality Technology Next Generation Reference Architecture
On the other hand, there are also illustrations of business where “shared” items are at the center, and non-shared items are “at the edge”. Illustrations like this one are also quite easy to find:
Source: United Nations Office for the Coordination of Humanitarian Affairs
In business architecture, do we illustrate “core” things to be “shared things at the center of a circle” or do we mean “core” to be “the most important things?”
In Enterprise Architecture, the distinction becomes more problematic. Shared things are often the LEAST important thing from the perspective of the business, not the MOST important thing. For example, the HR department is often a shared function, and unless the company is an HR service provider, that business function is not part of the value stream. On the other hand, from the perspective of information architecture, the shared things are the most important and the non-shared things are the least important. For example, a single understanding of “customer” is critical, especially when that understanding is shared across marketing, sales, and customer service. It is shared, common, and very important.
Now, add a specific use of the word “core” that is used in EA: the notion of a “core diagram” as described in the book “Enterprise Architecture As Strategy” from Ross and Weill. In that sense, the diagram itself may vary depending on which one of the operating models is being used, but the model itself is a shared, common understanding of the key items that are shared (whether that is process, information, or both). In that case, the thing that is important is the thing that is shared. That is called “core.”
Two years ago, I made a presentation to the Open Group conference about creating core diagrams using a method I created called “Minimum Sufficient Business Integration.” In that method, I use the word “core” many times to refer to “shared” items that are central to an organizations’ Enterprise Architecture.
So, what definition should I use for “core” when having a discussion about business and enterprise architecture? Should the word “core” refer to “the most important” thing, or “the most shared” thing?
I don’t have a good answer. Perhaps the best answer is to avoid the word “core” altogether.
By Jim Hietala, VP, Security, The Open Group Health IT professionals have always known that interoperability would be one of the most important aspects of the Affordable Care Act (ACA). Now doctors have financial incentive to be proactive in taking … Continue reading →
What’s on the agenda for 2014?Details of this years IRM EA Conference are now available. As usual, there is an interesting mix of topics – ranging from the introductory to the more advanced. I always find it interesting to look at the topics covered as it gives an indication of what organizations are doing and…
By The Open Group We recently spoke with Jim Hietala, Vice President, Security for The Open Group, at the 2014 San Francisco conference to discuss upcoming activities in The Open Group’s Security and Healthcare Forums. Jim, can you tell us … Continue reading →
By Allen Brown, President and CEO, The Open Group IT today is increasingly being driven by end-users. This phenomenon, known as the “consumerization of IT,” is a result of how pervasive technology has become in daily life. Years ago, IT … Continue reading →
By The Open Group At the recent San Francisco 2014 conference, The Open Group Trusted Technology Forum (OTTF) announced the launch of the Open Trusted Technology Provider™ Standard (O-TTPS) Accreditation Program. The program is one the first accreditation programs worldwide … Continue reading →
It’s probably no surprise to all of you that there has been a significant amount of talk about Business Architecture in recent years. Just coming back from the Open Group Conference in San Francisco it was one of the key…