Many companies don't like to admit it, but there is a huge disconnect between business and IT in the enterprise. While SOA and BPM can cut costs, business architecture has the potential to bring real change to the enterprise through the alignment of IT capabilities and business functionality. This alignment is one of the driving forces behind SOA. The SOA Consortium's Enterprise Architecture Working Group for 2010 has written a guide
for approaching the creation and gameplan for business architecture and business-driven SOA.
The working group says that business-driven SOA involves a portfolio of business, information, or technology service capabilities. Those services, along with events, rules, and policies need to be organized into business processes and solutions that fulfill business scenarios. Finally, (and obviously) work must be aimed at a business outcome. This could be cost and complexity reduction through a new IT portfolio, for example. "Business-driven" doesn’t mean having the business focused people always tapping you on the shoulder, it means everyone should be executing an action for business reasons.
Building a business-driven SOA is aided by the creation of a business architecture (BA). Business architecture is a 'formal' representation and active management of business design. IT and business architecture influence each other in two ways. First, BA provides important guidance for technology architecture, IT planning, and business solution delivery. In the other direction, IT influences business design choices through the identification of technological capabilities and trends.
The working group says that to get benefits like business agility and visibility out of BA, it must reflect the whole business design through the viewpoint of business architects and leaders, not the IT solutions delivery. However, this doesn't mean you shouldn't listen to IT people when it comes to capabilities and technical expertise. The business point of view transcends IT representations, such as business services, rules, events, and information models, according to the working group. The group believes that BA artifacts, which include business motivation models, capability maps, value chain maps, process models, policy documents, organization charts, and product catalogs should be managed in a repository.
There are a variety of artifacts, techniques, and notation languages for creating a business architecture. Techniques such as Lean, Six Sigma, and Value Chain Analysis and artifacts such as SIPOC diagrams, value stream maps, and value chain diagrams are all good examples. The working group suggests Nick Malik's Enterprise Business Motivation Model (EBMM) for notation. It contains seven core models (Influencer, Driver, Business Unit, Business Unit Capability, Business Model, Directive, Business Process and Assessment) that provide traceability from business motivation to managed IT service. According to the working group, the organizations performing true business architecture and analysis techniques, such as capability mapping, value chain analysis, and enterprise information modeling were having much more success than organizations performing solutions and systems analysis techniques.EBMM Model