I have had the privilege to experience the Microsoft Motion and the IBM Business Component Model approach. 1. IBM Business Component Model: This model is their generic model. IBM has created industry specific models whereby it is an extension to the Business Component Model. One of these extensions is the Insurance Application Architecture (IAA) which is a set of insurance specific models. IAA comprises of Foundation Models (insurance terms and definitions for communication and standardization); Information Models (insurance data content for an enterprise-wide view of information and data rationalization); Process Models (insurance business processes content for areas such as business process modeling, simulation and execution); Service Models (business services content for component based development and services oriented architectures); Product Models (a method for accelerating insurance product design) IAA has its own specific Business Component Model related to the insurance industry. The model gives a business-view which was very insightful for the our IT division for the business functions could be described on one page. The same page could be used with discussions with business stakeholders to link areas where improve or the areas which aligns with the business strategy which forms the potential Heat Map. The underlining detail for each function provides the relationship to other functions as well as those functions that is re-used which highlights the possibility of shared services within the enterprise. The IAA Business Component Model is business function driven and the underlining models are product, process, role and data driven and the interrelationship between these models. 2. Microsoft Motion: Microsoft Services uses their Microsoft Motion Methodology. There Business Architecture Services is a solution-centric approach whereby the purpose is to identify areas of optimisation with regards to where their solutions are utilised. A capability is defined as “An encapsulation and configuration of relevant resources, including people, information, and technology, that the business relies on to achieve a specific purpose or outcome”. The capability map is defined as by separating “what” is done in an organisation, at both high and detailed levels, from “how” it is done, in terms of people, processes, IT and other views, an inherently more stable and objective view of the business and the organization is exposed. Their capability map was developed to align the Business and IT capabilities by mapping the interrelationships to what business can do to what IT can do. Each business capability is measured with regards to business value, maturity, interconnectedness, compliance, performance and key metrics. The outcome is a detailed Heat Map which could be used for business and technology roadmaps to ensure business and IT alignment. Hope the above information was useful.

All – First, I am glad to see all of you engaged in this discussion because it demonstrate relative maturing of the industry. It seems, however, that many of the posts are working under the assumption that a definition of capability and its relation to value stream, process and other aspects of the business architecture do not exist. To the contrary, these definitions and associations are defined in practice, in the standards community and in literature. OMG BASIG site - http://bawg.omg.org - has white paper and related references. For example - "VDM [value delivery metamodel] supports the relationship between a capability and its usage as a value related activity; the existence of variations for a capability; and the association of capabilities to the comparative differentiators that they create." This reflects standards work in progress. Further, in practice and certainly shared through public courses through the BAI, we have consistently and continuously linked capability (defined as the 'what' a business does) to organization unit, value stream stages, processes, information and initiatives - to name the most common associations. In addition, in our new book - "Business Architecture: The Art and Practice of Business Transformation", due out in Dec. 2010, Neal McWhorter and I provide models, actual examples and diagrams of these associations. One final comment: Component is not a best practices domain within business architecture and no attempt has been made by OMG members (including IBM) to insert this concept into metamodels or standards at OMG BASIG. Search http://bawg.omg.org for models, glossary and other references. Hope this helps everyone. The standards community can definitely use more arms and legs on this effort so please join us. - William Ulrich, TSG, BAI, BASIG, BAGuild

@Karen, and @Adrian -- Since IBM's CBM has come up here, I would be willing to entertain off-line discussions of that. I practiced and taught it while I was still with IBM, but if you're interested in *anything* I've posted at enterprisology.com, frankly when CBM came on the scene (from PWCC), it sucked all the oxygen out of the room for any other interesting business architecture perspectives. Maybe it's changed now -- it's been awhile since I moved on from Good Ol' Blue ;-) At the height of the CBM frenzy, I participated in an effort headed by IBM Research, where we encountered that MS Motion video, when it was new (2006). I worried at the time that it seemed so much advanced, but then I have never encountered it in the marketplace. Seems as if some of these things have been dragged down with SOA into a low point on the Gartner hype curve. Or maybe I'm just not looking in the right places.

Alexander, an interesting response! However, what is your organizing principle or purposeful reason for integrating those processes? I sense it is customer (consumer, client, end user, etc). I would find your approach far more appealing and much more agreeable if it were clearly and more explicitly “customer-centric.” A process-centric enterprise might be considered “on the way” to a customer-centric enterprise. And a process-centric enterprise can coexist quite harmoniously within a customer-centric enterprise.

Adrian, the more we discuss a generic BA, the more we seem to agree! For example, consider the first sentence in your last post, “I agree that without end to end business processes you cannot really illustrate an architecture.” By the way, I am seeing more convergent thinking like this with other discussion groups, BrainStorm conference colleagues and clients as well. So much so that I wrote an article for BrainStorm last December titled: Converging Business Architecture (BA) Approaches; http://www.bpminstitute.org/articles/article/article/converging-business... . With a focus on the customer (or consumer, client, end user, etc.) the enterprise design has a meaningful purpose. Many have probably sometimes heard this referred to as an Outside-in view. The functional view, sometimes referred to as an Inside-out view, obscures the reason why the enterprise exists, which is to create profit by serving its customers, not its functions. The functional view of the enterprise is very different from the value stream view (or Business Flows view in your terms). As you realize, each has a different organizing principle. If one starts “first” with building an architecture based on value streams using the traditional functions, processes and activities of the enterprise as building materials, then one begins to change the behavior of the enterprise to that of becoming more and more “customer-centric.” (And of course, the focus on a client, consumer, guest, passenger, patron, citizen, end user, stakeholder and other similar terms are just as valid as customer.) This provides a “purpose” for the organizing principle of the BA, that of a focus on the customer. However, since the functions (or building materials) are not designed with a focus on the customer, many functions will have to be changed, updated, re-engineered or adapted to support a customer-centric view. One can then derive or reconstitute a new functional model from the value stream model if one finds this necessary. Then one can map to the traditional functional relationships found throughout the enterprise. Nonetheless, I would still like to review an “example” of a functions/capability map, so as to better appreciate its relevance to BA/EA. Perhaps many use this artifact as a transition to value streams; I do not know, but would still enjoy analyzing an example from the public domain. Many enterprises are standing at a crossroads today, considering or perhaps reconsidering a choice between staying put in the traditional “functional mindset” or expanding up to the “value stream mindset.” Please realize that “expanding” also implies “using.” One might say that this is the beginning of a long and difficult journey! I find it appealing that the GODS approach has expanded up from the traditional “functional mindset,” with value streams (or Business Flows in your terms) and as you stated in an earlier post, “GODS is customer oriented. At the top of the blueprint are the customer channels and interactions for the demand creation, sales and services flows and so on.” I believe you had to expand your approach to overcome the consequences associated with, for example, “vertical silo” or “stovepipe” functional enterprises. I also had to expand up from functional thinking for the very same reasons and chose James Martin’s value streams. And I very much preferred the association that value streams have in other disciplines, such as Six Sigma and Lean Manufacturing. So, we both have expanded our thinking in the same direction; that of a focus on the customer! I simply chose a different way to represent that “expansion in thinking;” I chose value streams and illustrated this architecture in my web site case study models! You chose the representation illustrated on your web site. This also enables you to directly map to the corresponding “functionally” related IT systems and organizations. And I too, can map to the corresponding “functionally” related IT systems and organizations, but I do have to transition back to the functional view from the value stream view; and this is quite logical, but not difficult. However, I believe the discipline enforced by value stream thinking has a most profound impact on corporate behavior; designing the enterprise around results delivered to customers! At the end of this a long and difficult journey, I believe we will find a newly evolved enterprise with a crystal clear focus on the customer using value streams, rather than just merely a traditional functional focus. This does not mean that functions, functional models, or functional relationships will disappear or become irrelevant, just that these artifacts will have a somewhat diminished value, and will no longer reside at the core of a truly customer centric enterprise!

Adrian, I agree that “an architecture is about components in interaction, about structure and behavior.” As you stated, the “GODS business architecture does describe key business functions in interactions implementing key business flows.” If one can do that with functions, then one can certainly do it with value streams as well. However, functional alignment does not “see or view” the results of end-to-end cross-functional integration of processes and activities with a focus on the customer; you need a value stream to achieve that visibility. This is the advantage of value stream thinking in today’s “Information Age” over the traditional functional thinking from the “Industrial Age.” Building a generic BA based on functional thinking is certainly possible and useful; and so is building a generic BA based on value stream thinking. A review of my case study model will reveal the interaction, structure and behavior of the EBA and hopefully its usefulness as well. Building a generic (or real) BA using Martin’s value streams is, for example: • focused on the customer (or consumer, client, end user, etc.) • integrated with end-to-end cross-functional processes and activities • designed to deliver results to the customer (consumer, client, end user, etc.) • intended to delight the customer (consumer, client, end user, etc.) • measured by an objective(s) in the strategy • uses the functions, processes and activities typically found in an enterprise as building materials As for EA aligning technology systems to business functions, I consider this an “IT-centric” view (or perhaps a bottom up view), one that we all have used for years. A point discussed on your web site which is posted in the first comment of this discussion. One can align business functions to technology systems from a top-down perspective, too, but functions are seemingly purposeless and frequently associated with “vertical silo” or “stovepipe” type consequences. However, enlightened by James Martin’s book, The Great Transition, I now prefer the “customer-centric” view (or the top down view). The design of my EBA approach using integrated value streams initially aligns the technology systems to value streams, but also enables the transition back to the traditional functional view as well. After all, if you truly have a BA with an integrated set of value streams, then it must allow an orderly decomposition down to its most basic elements and then reconstitution, reconstruction or aggregation back into functions or other desired views, such as an organizational view, or for other necessary purposes. I can illustrate this from my web site, the decomposition and aggregation back into functions, but I have to load up the models as they are not normally available on the web site. We know the world of IT is clearly moving and has been moving in the direction of services (SOA) for some time now. And these services are grouped or organized, usually according to functions; but what if the services were grouped or organized according to value streams? Hmmmmm…….! Then the enterprise would almost have a “natural alignment” of IT to the business using a customer centric focus. Are we beginning a period of transformation or natural evolution here? A generic BA, such as represented in GODS can very well define today’s enterprise and another generic BA using value streams can offer a different view or perhaps a futuristic view of the enterprise; a customer centric one, but NOT one that is in conflict with GODS! I think both views, functional and customer-centric offer significant opportunities for enterprises to consider for research and analysis. Again, I would still like to see a capabilities map which manifests the definition of capability that is available in the public domain, but I have not been able to find one. If anyone knows of the presence of a functions/capability map on the web, please post a reference in the discussion.

In order to use any browser other than IE to view the EBA case study models, please go to my web site where one can find my email address in the “Contact Us” link or just use: rwEBAauthor@enterprisebusinessarchitecture.com . Please provide me an email address and I will send a MSWord document containing “manual hyperlinks” to all of the EBA models. Then one can use any browser to view the models, but it will take a little more time to “manually browse” through the case study. Then, one is welcome to view and analyze the EBA case study models as desired. I also agree with Adrian that the EBA/BA requires integration within any EA framework (e.g., Zachman, TOGAF, etc.) And yes, my approach to building the EBA/BA provides a simple way to integrate with other Enterprise Architectures; the IT, Security and Organizational Architectures. The EBA/BA artifacts were designed to link to the traditional EA artifacts with minimal interpretation and through a natural progression. I also have some examples of typical EA artifacts on my web site, but I have to setup special access to these models. The co-author of my book and I are also co-inventors of a patented Strategic Business/IT Planning Framework similar to the Zachman Framework. One can find the patent at: http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL... . The EBA approach we developed uses James Martin’s “value stream” as the organizing principle. And value streams are well understood and used in Lean Manufacturing and Six Sigma initiatives. “The value stream is an end-to-end set of activities that delivers results to a customer.” And of course, the focus on a client, consumer, guest, passenger, patron, citizen, end user, stakeholder and other similar terms are just as valid as customer. But, the rationale for using value streams is that it provides a “purposeful reason” for integration; a focus on the customer! Functions are generally classified processes in vertical silos or columns, seldom integrated and NOT purposely designed with a focus on the customer. I do not like equating capabilities to functions or as an alias of functions. There is no progress there! Functional thinking is an “Inside-out” view of the enterprise, whereas value stream thinking is an “Outside-In” view. Some may prefer starting their EBA initiative with capabilities and a capabilities map. The term “capabilities” is broadly defined and widely used! I would like to see the formal definition of “capabilities” just as I provided a formal definition of value stream. Additionally, I would like to see a capabilities map which manifests the definition of capability that is available in the public domain for analysis and scrutiny. I am open and interested in capabilities, but I just cannot find a capabilities map in the public domain to review! If you build the EBA with customer-centric value streams, and then you derive and integrate the EBA with the IT, Security and Organizational Architectures, the final result is not only enterprise-wide alignment, but an EA built with a “purposeful” customer-centric view. As Martin says, the “value stream has a clear goal: to satisfy or to delight the customer.” Therefore, a generic EBA is better represented by a customer-centric view.

Adrian, please consider looking at my web site: http://www.enterprisebusinessarchitecture.com/ and follow the links in the first paragraph to the "case study example." Please use Internet Explorer as the hyperlinks in the models were configured for this browser. The “HELP” link in the upper left corner of the first page of the case study, illustrates navigation though the models from top to bottom. The Enterprise Hierarchy link in the upper right corner provides a Bill of Value Streams view (metaphorically equivalent to the Bill of Materials for a manufactured product) and an opportunity to take a “random walk” through the case study. Just click on the rounded square for Widget, Inc. and then click on the vertical rectangles to view the models. This EBA is for a rather "generic" build-to-order manufacturer. However, I cannot envision a generic EBA for all enterprises! I could envision a somewhat generic EBA by industry with a unique focus on industry specific integrated components, while sharing other generic enterprise integrated components.