01/05/2010

SOA Consortium EA2010 Working Group’s Business Architecture Paper Now Available

The SOA Consortium’s EA2010 Working Group – a group of “street-smart” enterprise architecture practitioners – has been actively discussing the domains, services, practices and skills required for a thriving, business relevant enterprise architecture practice in the 2010s.

A critical finding of these discussions is the emphasis of technology concerns at the expense of business understanding, and ultimately, true business enablement, in most enterprise architecture practices today. Successful enterprise architecture practices in the 2010s must give equal emphasis to technology and business concerns. The means for this re-balancing is the elevation, and in some cases initial adoption, of business architecture practices.

Typically, the business architecture practices and artifacts in enterprise architecture frameworks focus on business processes and business uses cases. This is not surprising, since these artifacts and practices are a prerequisite to IT-based business solution delivery. However, this is not sufficient.

To reap the benefits of business architecture – business visibility and agility – the business architecture must reflect the entire business design, from the point of view of business designers and owners, rather than IT solution delivery. This point of view begins with business motivations, includes key business execution elements – such as operating model, capabilities, value chains, processes, and organizational models – and transcends information technology representations, such as business services, rules, events and information models.

While we strongly believe that business architecture is a business domain, the Chief Information Officer (CIO), given his/her unique position to view business plans, business processes, information flows, and technology portfolios across the organization, most often champions business architecture formalization.

In this discussion-oriented paper, the EA2010 group shares their findings on the following questions:

• What comprises business architecture? • What is the purpose? • Who participates? • How do you make business architecture accessible? • How does business architecture facilitate business decision-making and change? • How do you keep business architecture current? • How does business architecture relate to BPM, SOA and IT solution delivery?

Comments

You can follow this conversation by subscribing to the comment feed for this post.

Borrowing money to start a busniess to sell stuff peolpe can't afford. So you just add debt that can't be paid. Never mind lowering taxes, thats to easy, lets instead lend money to start or help keep open businesses so we can keep taxing the crap out of them. This is like offering a line of credit to peolpe who can't pay their bills. Sure it would help them for a few months, but in the end, they have a debt they can't pay. Instead, lower taxes would do more in both accounts.References :

Just in case someone is interested... Yesterday, I finally published my PhD thesis (http://sebstein.hpfsc.de/phd), which is title "Modeling method extension for service-oriented BPM". I extended the EA framework ARIS to incorporate SOA concepts on a technical level, but also on an enterprise architecture level (i.e. business services).

The extension was added to the official ARIS SOA products and is readily available.

Boris Lublinsky wrote about the EA2010 paper on InfoQ, his conclusion:

"Whether we like it or not, at the moment there is a huge disconnect between business and IT. Any attempts to use SOA/BPM approaches for improving the way we are building IT applications might make their implementation more cost effective, but will do very little for changing the status quo. On another hand - using business architecture to directly align IT capabilities with enterprise business functionality provides a path for establishing significantly better cooperation between business and IT. Such alignment was an initial SOA promise ( and still continues to be one of the main SOA drivers), so it seems that creating/improving the business architecture should be a significant part of the SOA."

Frankly, I doubt the practicality of comprehensive business architecture and its active management, especially when EA is typically driven by IT organization. In the typical large organization's power structure, I feel, it is impractical and in fact, counter productive. I try to explain my opinion @http://amitunde.blogspot.com/2010/01/business-architecture-is-it-its.html

Having said this, I feel, the paper is very useful. I would like to congratulate authors for beginning the dialog on this subject and would like to encourage OMG to work on much needed Business architecture modeling standards.

We at EA-2010 approached the subject of Business Architecture purely from the perspective of how BA can be used to deliver real value to the enterprises, that ARE the ultimate cosumer and hopefully beneficiary of the BA discipline. We have explicitly stayed away from endorsing any specific standards body or methodology. We realize that there are probably multiple definitions, methodologies that can be used in different situations.

We are grateful to have OMG provide us with a platform and resources to promote the dialogue while allowing us the luxury of independent thinking. We can use this opportunity to really collaborate to the benefit of the "customer". This in turn will also shed a positive light on the practice of EA and the members of its community.

As one of the contributors to the paper, I can certainly say that we did not mean to ignore the OMG BA Working Group's definition (or any other). I think we were taking a broad look across the various contributors' experience in their respective organizations. We're also aware, as is evidenced by the thread above, that there are still multiple definitions around. We could say the same thing about definitions that we say about standards: "we love them so much that we have several of them." As we said in the preamble, this is a discussion paper, precisely meant to elicit additional input.

We should certainly pay attention to definitions already established, within the OMG or elsewhere, and what these say about the understanding and scope of the subject. I am quite happy to see the beginning of a dialogue on this here. I'm interested in what the direction will be at the OMG, following the "promotion" of the Architecture Board's BA SIG. And Bill, I'm sure that the authors, including me, will want to understand better what the Enterprise Designer Institute offers, and also how it relates to other BA related organizations, such as the Business Architects Association mentioned by Keith.

Keith, I understand that the BAA is focused on the definition of the profession and not on the actual definition of business architecture, the underlying knowledgebase, or the visualizations. The BASIG, in conjunction and with support from the BAI, BAS, and in coordination with the Open Group BAWG, is working on the latter. I fail to see how one can define the role of the business architect without defining the essence of business architecture.

Bill, Come and join the BASIG and maybe your framework can be incorporated into or aligned with our standards. We all want to promote our company solutions but the results will be much more far reaching for you and every other vendor if there are not 30 frameworks and 30 definitions in the marketplace.

This is a great conversation and long overdue. At the Enterprise Designer Institute we have been working for the past five years to create a simple business architecture framework and methodology. Our approach identifies 26 elements which can be combined together. The methodology focuses on the organization through the eyes of the customer to identify what is critical from their perspective. The framework sits above other frameworks and provides the overall business context. We have tested it in many situations including government, utilities and telcos and it seems to hold good. This is perhaps not the space to describe the approach in detail but those who are interested may wish to visit the EnterpriseDesigner.com website where there are a number of free resources.

William, I read your comment on the recently published “SOA Consortium EA2010 Working Group’s Business Architecture Paper”, and agree that having a standard and agreed to definition of this emerging field is critical. Unfortunately as the field is evolving members of the consulting community are making marketing plays in defining the “space”, typically definitions which refine their consulting practices. As a board member of the Business Architecture Association (http://www.businessarchitects.org/), we are working hard to create not only the definition of this profession, but equally important the tools, methods, and “real” examples of how BArch is leveraged in businesses. Much work was been done in 2009 including a formal competency model and matrix, job descriptions, an overview of a “career as a BArch” as well as expanding the certified training currently made available through the association as well as industry white papers on how BArch has and is being used across organizations, applications which extend beyond the IT realm.

Look for more materials in 2010 from the Business Architecture Association promoting the field on behalf of all Business Architects.

I read with interest the paper titled "". Most interesting was the EA2010 Working Group's definition of business architecture. It stated that: The EA2010 working group defines business architecture as the "formal representation and active management of business design. Expanding this definition, business architecture is a formalized collection of practices, information and tools for business professionals to assess and implement business design, and business change."

This is not the generally accepted definition of business architecture as posted on the OMG Business Architecture SIG homepage (http://bawg.omg.org), the Business Architecture Institute site (www.businessarchitectureinstitute.org) or even Wikipedia. Given that the OMG manages the SOA Consortium, I would have anticipated that the working group would have adopted the definition agreed upon by its own working group (now SIG) membership - a definition that has general agreement across the industry.

While I laud the fact that the SOA Consortium is now on board with business architecture, albeit from an IT perspective, it would be constructive if SOA Consortium would use the established definition of the term so as not to further confuse the masses.