InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Business-Driven SOA

Posted by Boris Lublinsky on Jan 13, 2010

Sections
Architecture & Design,
Enterprise Architecture
Topics
Architecture ,
Business ,
SOA ,
Design
Tags
SOA Adoption

 

SOA Consortium started 2010 by releasing a new whitepaper - Business Architecture: The Missing Link between Business Strategy and Enterprise Architecture.

The white paper defines "business-driven SOA" as a combination of the following:

  • Creating a portfolio of services that represent capabilities offered by, or required of, your organization. Those capabilities may represent business, information, or technology concepts.
  • Composing or orchestrating those services along with events, rules and policies into business processes and solutions that fulfill business scenarios.
  • Working towards a business outcome. That "business outcome" could be cost and complexity reduction via a rationalized IT portfolio. In other words, "business-driven" doesn’t require a business person tapping you on the shoulder, it means executing for business reasons.

According to the whitepaper, a prerequisite for creating business-driven SOA is the creation of the business architecture - a "formal representation and active management of business design"

 

The whitepaper explains that:

The relationship between business architecture and information technology is two-fold. First, business architecture is a critical input to IT planning, technology architecture and business solution delivery. Second, technology trends and IT capabilities influence business design choices in the realms of capabilities, value chains, processes, and channels... The interdependencies of business architecture and information technology call for collaborative practices and organizational models. This connection is best structured as a true enterprise architecture practice, one that gives equal emphasis to business and technology concerns.

According to the whitepaper, many of the current business architecture approaches are focusing on the prerequisite to IT-based business solution delivery - business processes and business uses cases.

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.

The whitepaper suggests treating business architecture as a formalized collection of practices, information and tools for business professionals to assess and implement business design, and business change.

  • Business architecture must encompass the entire business design, from the business designers’ and owners’ points of view. 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.
  • Business architecture is formally represented via a variety of artifacts, including business motivation models, capability maps, value chain maps, process models, policy documents, organization charts, and product catalogs.
  • For ease of accessibility, the business architecture artifacts should be managed in a repository.

The whitepaper defines business architecture as a mechanism for defining how strategy, processes, business structure and staff can be best utilized to deliver reliable and cost effective operations.

Technology enablement is key to the majority of new functions and services. Business architecture helps organizations define the technology requirements and capabilities clearly, yielding IT plans and projects that align with business priorities and goals.

Additionally, the whitepaper provides some actionable information on how an organization can approach the task of creating the business architecture and the place business architecture should take in the enterprise. It also describes business architecture in action - practical steps that an enterprise can follow to create, leverage and improve its business architecture.

Finally, the whitepaper discusses the relationship between business architecture and several critical business and technology constructs, including business-IT alignment, business process management (BPM), service-oriented architecture (SOA) and business solution delivery.

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.

  • This article is part of a featured topic series on SOA
Business - IT Disconnect by brenda michelson Posted
  1. Back to top

    Business - IT Disconnect

    by brenda michelson

    Boris,

    Thanks for sharing the EA2010 community paper with your readers. Nice closing point: "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." IT efficiency is good, but true business-IT collaboration takes the next step, enabling business capability optimization.

    Brenda

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.