Archive for the 'SOA' category
SOA-Thesis Published
April 6, 2007Diploma Thesis Finished!
November 18, 2006Reference Model for Service Oriented Architecture (SOA-RM) Approved
October 29, 2006Book review: Service Orient or Be Doomed! (Bloomberg, Schmelzer)
October 15, 2006Bloomberg, J.; Schmelzer, R.: Service Orient or Be Doomed! : How Service Orientation Will Change Your Business. First Edition, Hoboken: Wiley, 2006
The exceptional title lets already assume that this book is different from others in the area of service orientation - and yes, it is!
As the authors state, their approach to the topic is that “this is a book about business concepts, where the business concept at hand is how companies can best leverage technology resources to meet their business goals.” They want to talk “about a range of business problems that are preventing companies from being efficient and competitive and then discuss the new approach [they] call Service Orientation to leveraging business resources to solve those problems”. So although there is a lot of technology in the book the approach is different. Whereas typical business/IT books according to Bloomberg and Schmelzer take the approach “Here’s some great technology, now let’s see what we can do with it”, they prefer the way “Here are some difficult business problems, let’s come up with a great way to solve them”. So when talking about IT, they are talking about “a set of business resources available to solve business problems”. The motivation for it is that “Service Orientation and the related technology concept Service-Oriented Architecture (SOA) are new approaches for businesses to leverage technology in a flexible, agile manner.” Therefore they want to “free this powerful concept from the clutches of the techies”.
By the way, the difference between “techies” (nerds / geeks / technologists) and “suits” (business people) is discussed very intensively at the beginning, so although the differences for sure exist, after a while I couldn’t here it anymore and got a bit bored. But maybe that’s because considering my studies (Business Informatics) I would classify myself more into those “technology/business crossovers”. So if neither business nor IT is completly new to you and you also heard about service orientation and the evolution of the internet before, you can jump directly into chapter four or five.
Maybe that’s the way business books are written, but (as an academic or a techie:) one has to be aware that not only the title is different from other SOA books I’ve seen before but also the way the content is written. The writing style is rather colloquial and the topics are introduced broadly. “It’s a pretty heavy concept that has far-reaching business implications. To explain it, therefore, let’s step back and tell a tale.” This statement found at the beginning of chapter 5 before explaining the concept of loose coupling, in my opinion is also true for most other parts of the book. So although there is a “Jargon Watch” to shortly clarify important terms which are touched while explaining, the terms which are really important in the context of the book (loose coupling, service orientation, architecture, …) are explained throughout several pages and including many aspects but unfortunately without a short summary or definition at the end. There are only one cost chart, three graphics (showing a “rats’ nest”, SOA view model and the two spheres of service oriented development) as well as one unreadable picture of the Zachman Framework, which in my opinion is not very much in order to back up the message of a whole book. But enough with those formal aspects now, because I really don’t want to say that the style is not good. It’s just important to know what to expect when ordering online.
Because in fact the content of this book is really good. The authors seem to have a lot of experience in the area of service orientation and in my opinion the approach from the business side (or the user side) they take is very important and useful. Not to say that IT-related problems like communication protocols, transaction concepts or security aspects should not be discussed in the SOA context (both sorts of books are needed) but I think its better to have first a clear vision what is best from the business or users perspective before thinking about how to get there by means of technology. Otherwise it can get very narrow-minded as you maybe don’t detect new possibilities at all because the technology might not (yet!) be ready to solve the problems completly in an easy manner.
The book includes the following chapters:
- The Business Inflexibility Trap
- If You’re in a Hole, the First Thing to Do Is Stop Digging
- What Really Happened to eBusiness
- What Do You Want Your IT to Do, Anyway?
- The Secret Sauce: Loose Coupling
- Service Orientation: Light at the End of the Tunnel
- Is There an Architect in the House?
- How to Think Service Oriented
- Okay, So Where Do We Start?
- Tackling the Inertia in the Organization
- Build Agility with Agility
- Becoming a Service-Oriented Enterprise
My advice for this book: Go and get it, it really stands out from other books in the way service orientation is described. I would even say it is useful not just for “suits” but also for “techies” or at least “crossovers”, which want to understand why the managers tell them service orientation is a new approach although they are still coding Java, C# or ABAP. But don’t expect to get fast facts on the different aspects of service orientation. Rather sit down in the evening, open up a beer and listen to the tales the authors have to tell - because what is finally important is that the tales are not fantasy tales but real world tales!
SOA Standardization Efforts
October 15, 2006McGovern, J.; Sims, O.; Jain, A.; Little, M.: Enterprise Service Oriented Architectures : Concepts, Challenges, Recommendations. First Edition, Dordrecht: Springer, 2006
According to McGovern et al. three major concepts are the basis of enterprise service-oriented architecture (ESOA):
- Services using XML-based standards both for specification of the service interfaces and for communication with the services (that’s what they say many refer to as just service-oriented architecture).
- Service implementation using component-based software engineering (CBSE) architecture for structuring new applications as well as for legacy wrapping, workflow and business-to-business specifications.
- A service-oriented architectural, procedural and organizational mindset, which can merge web service technology and the CBSE approach into a hughely productive whole.
The use of CBSE for service implementation is intensively discussed especially in chapter 3. Following the authers there has been a shift in the evolution of mature CBSE “from reuse of components as pluggable modules of software technology to business-oriented reuse and business collaboration of business services - the components themselves being the service implementations.” They differentiate levels of utility components, entity components and process components. Entity components are business entities such as invoice or customer, They make use of general low-level utility components and are used by process components. The authors refer to that as “federation”, which basically means the same as that higher-level components choreograph those at lower level.
They identify three reasons why, although many commercial off-the-shelf (COTS) products exist, implementing an ESOA is difficult:
- COTS products are point solutions, not ESOA solutions, that is there exists no single integrated product.
- They are general-purpose suitable for many architectural styles, so they are not so high-level as a platform focusing on one architectural style could be.
- IT development is (typically) project-based, that means there is little funding outside of the project and there is limited reuse of common artifacts across projects.
As the lack of an end-to-end cohesive product is seen as the major inhibitor limiting productivity they ask for an “enterprise productivity platform” (EPP).
In chapter 3 a procedure for designing service components following CBSE principles is proposed.
They start with a definition of business elements derived from resource and process models. There exist Resource Business Elements (RBE), Service Business Elements (SBE) and Delivery Business Elements (DBE). RBEs consist of a set of resources grouped around focus resources which are real and independent. SBEs are a “collection of immediate steps” grouped by RBEs - they will normally map to organizational units. DBEs are a “group of Service and Resource Business Elements that together deliver a business solution to a business problem, and which provides services to requestors”. They can represent a major responsibilty of a department or a larger organizational unit. So whereas RBEs are useless themselves because there is no process, SBEs need RBEs to have resources. The DBE “is the set of assets that delivers value”.
A Service Business Element is later mapped to a Process Business Component, a Resource Business Element to a Entity Business Component and a Delivery Business Element to an Applicaion Component. Using Model Driven Architecture (MDA) terminology this would mean the business elements are part of the computation-independent model (CIM). They are mapped to components which are later refined and describe the platform-independent model (PIM).
The books consists of further chapters, which I won’t introduce in detail, namely “Orchestration”, “Working with registry and UDDI”, “Understanding Enterprise Security”, “SOA Management”, “Transactions” and “Event-Driven Architecture”. It references other books, documents and magazines in case ideas have already discussed somewhere else (which is not self-evident considering many other SOA books), so it can be said to have a rather academic writing style. Graphics, screenshots and code snippets are used to visualize the statements.
