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.

I.T. SOA vs Business SOA?

Posted by Mark Little on Aug 20, 2008

Sections
Process & Practices,
Architecture & Design,
Enterprise Architecture
Topics
Stories & Case Studies ,
SOA ,
Methodologies
Tags
IBM ,
SAP
In a recent post Jeff Schneider discusses separate conversations he's had recently with people from IBM and SAP in which they are talking about differentiating between I.T. SOA and Business SOA. The former helps you to run a more efficient I.T. group, whereas the latter is about creating new information products and capabilities. Several years ago Steve Jones spoke about Technical SOA as the drug of choice for I.T. departments, so maybe when IBM or SAP talk about I.T. SOA they mean Technical SOA?

According to Jeff, SAP ...
... have positioned SOA as a technology enabler to their large suite of business applications. They sell [SOA based] business solutions.
... which does seem a bit circular in nature. However, Jeff is pleased that this means IBM and SAP are assuming that SOA is in place acting as an enabling technology. Therefore it's time to move past these enabling solutions, which includes ESBs and other possible implementations of I.T. SOA and concentrate on Business SOA.
In Business SOA we need to think about a new set of "Business SOA Patterns":

- How do we deliver new business products through new channels?

- How do we deliver more/better information to our distributors, retailers and consumers?

- How will consolidated/shared information lead to a tighter supply chain?
Related to this, Jeff has come up with what he called the 7 Dirty Words [of I.T.] SOA:
  1. Loose Coupling

  2. Abstraction

  3. Reuse

  4. Autonomous

  5. Discoverability

  6. Composability

  7. Interoperability
Maybe there has been too much emphasis on the technical aspects of SOA. But if so where does the blame lie? Surely some of this is this the fault of the technology companies such as IBM and SAP who (obviously) had those solutions to sell? Or as Steve says:
how [technologists] become obsessed with a given technology or approach and just can't help using it everywhere. Sort of like addiction ...
It is unclear though how this idea that I.T. SOA has reached a threshold ties in with reports that SOA is failiing, particularly when many of the reports emphasize technical aspects. Of course it is possible that those failures simply indicate poor technology choices, or alternatively to paraphrase Mark Twain: reports of the death of I.T. SOA are greatly exaggerated?
  • This article is part of a featured topic series on SOA

No comments

Watch Thread Reply

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.