The Soa Iceage

‘Oh, no!’ you might think. ‘Another one who wants to shove SOA as a means for corporate agility down my throat …’.

Relax, nothing could be more wrong. In short, I am certain that SOA does not improve corporate agility, rather the opposite. The problem is that SOA represent a prevailing vision in the eloquent diction of Thomas Sowell’s book ‘The Vision of the Annointed’. A prevailing vision automatically provides a status of higher intelligence to its proponents without the need for empirical proof or more detailed analysis. Opponents simply have non-disclosed darker motives.

Service-Oriented Architecture (SOA) was first proposed by Gartner Group in 1996 in a SSA Research Document as a logical evolution of losely coupled, object-oriented messaging interfaces. But many paths lead to Rome. For example, in 2000 Papyrus WebRepository as enhanced with a freely definable service adapter for HTTP and FTP and in 2001 with MQ-Series. In the following years Papyrus’ adapters were provided to support the most common messaging formats including SOAP and WSDL. Because Papyrus WebRepository is by design a state/event driven process engine with definable user front end, and it therefore provides the SOA core function – to create agile business services linked to encapsulated external services – since 2000.

Ok, interfaces are an important IT subject, but is it enough to invest in SOA? I am asking: „What can SOA do for the user?“ The answer of the SOA visionaries: “Agile processes.” I say that this is an unfounded claim with no sensible proof whatsoever. Agility is a capability of a living being that a computer infrastructure cam never posess. Agile manager and employees create agile processes with or without SOA and not the other way around.

Processes became popular in 1911 when Frederick Taylor proposed them as a means to organize a business scientifically. Rummler and Brache wrote in 1990, that ”a business process is a series of steps designed to produce a product or service for a customer.” This is an oversimplification that will only apply to at most two percent of all business processes. In ‘Reeingineering the Corporation’ Hammer and Champy enlarged on that by saying: “Not the individual task or process is important but only the outcome.” That makes a lot more sense and leads to the question: “Is it even possible to analyze rigid processes to achieve a certain business goal?” I seriously propose that this is an illusion!

It is my experience that emplyoess are inerviewed for month just to figure out a few simple processes that still are not correct once he get used. I ask: ‚How are these processes then continuously improved to finally reach the desired outcome?“ I tend to get pitiful smiles: „Obviously we use monitoring.“ Hold it, folks. Process monitoring only measures the service criteria of the analyzed process but not if it achieves the goals, right? „But we got Dashboards to monitor busines goals.“ Another one claims. True, some BPM products do, but even then it shows some value that maybe good or bad depending on the quality of the data source, but it DOES NOT tell you which process has to be changed how to get closer to your goal. You are back to square one. On top of that, you will find out that users will resist any change and a simple change needs a complete retest of all relates workflows because of the unknown dependencies.

Current BPM and SOA do not thaw the iceage that has befallen our applications. Java code is mostly frozen and thus dead. Business processes however have to be alive – call them agile if you want – but that has very little to do with SOA or what kind of interfacing technique you use. The people using those processes have to accept that it is them to create and modify the processes, which will never happen with any modelling tool that uses simplistic 2D step-by-step graphs, because of the hidden complexity. Only very innovative technology such as the Papyrus User-Trained Agent that can learn processes from user interaction, will provide the power of process tuning to the user.

Let’s take a step back. How did we do dynamic agile processes before IT? Very simple … by usng documents! So what we need most from BPM is an overview of all the states of all the documents of a particular business process. No one needs rigid processes that are monitored for inhumane perfection. Let me add one more: I propose that there are no ‚document related processes’ but if a process does not require a document then the process is not needed! Yes, some dialogs in BPM systems replace those documents but that just proves my point. In my 35 years in IT I have learned that there are no fragmented process steps, but the propagation of a process is implicitly contained in the interdependent summary state of all its content (data, documents, controls). Because content is mostly irrelevant in process analysis so many process models are either wrong, incomplete or require substantial user input.

Another subject is even more controversial. When we interview those users, how does one model their decision making into simple IF-THEN-ELSE rules? One has to know WHY a user made a decision and encode that. I propose that this is actually not possible and my proposal is based on Antonio Damasio’s research documented in his book ‚Descartes Error.’ Humans are apparently incapable of being purely rational and need emotions to come to a sensible decision. (I know that this is true for me, but then I am an entrepreneur and don’t have to be reasonable.) Human rationality as well as analytical fact is an illusion. We never know for sure and that’s why a good feel about what is going on is much better than rational decisions. Now if that is true, each and every BPM system on the market today is a waste of time and money.

Conclusion: IT and its processes lack today because of fragmentation.

This is true for IT organization with analysis, development, test and production; missing change management for SOA interfaces, process steps, rules, documents, and GUIs; as well as the chance split of BPM, CRM and ECM. To solve the above the end-user departments have to be willing and agile enough to create and tune their own processes, but they won’t succeed with 2D-graphs and rule coding. Only the Papyrus WebRepository manages all the changes from analysis, definition, and test to production, transparently across all operating systems all those process elements, including the SOA parts. A typical SOA, Java and XML application has data models and logic hidden away in the database tables, in the processes, in the Java development tools as well as in XSL, XSLT, DTD, XPATH definitions und finally in the SOA interfaces with no common change management mechanism.

Papyrus WebRepository even goes a step further. In December 2007, the User-Trained Agent will be generally available and enable the training of business processes from user interaction. The logic is much more powerful than simple rule coding because all content of the business process is considered in the transductive pattern matching learning process. The transductive training concept is patented and thus an ISIS exclusive. Yes, patenting and proprietary is good because it is innovative and functional. The time it takes to standardize kills innovation and solution orientation as the dramatically lacking BPEL 2.0 clearly shows.

Visions can’t be proven (sic), but agility mostly means to have the mental flexibility to innovate.

„There are two key areas where IT has to focus: Strategic change – including architecture, business process management and change management – and innovation.”

Barbara Gomolski, VP Gartner Group – Computerworld Opinion, October 2006

You can’t lead following in someones footsteps. IT benchmarks pull everyone down to the same low level and have no other purpose than to be a pseudo-proof for the prevailing vision.

Innovation – to do something new – always bears some risk. Be brave!

Bibliography and References:

Damasio, Antonio (2005) Descartes’ Error: Emotion, Reason, and the Human Brain, ISBN 0-380-72647-5

Draheim, D. & Weber, G. (2006) Trends in Enterprise Application Architecture, ISBN-13: 978-3540327349

Hammer, M. ; Champy, J. (1993), Reengineering the Corporation: A Manifesto … ISBN-13: 978-1863735056

Rummler & Brache (1990), Improving Performance: How to manage the white space … ISBN-13: 978-1555422141

Sowell, Thomas, (1996) The Vision of the Anointed ISBN-13: 978-0465089956

Taylor F. W. (1911) The Principles of Scientific Management, ISBN-13: 978-1434638205

Gartner Group SSA Research Note SPA-401-068, 12 April 1996, “‘Service Oriented’ Architectures, Part 1″

Gartner Group SSA Research Note SPA-401-069, 12 April 1996, “‘Service Oriented’ Architectures, Part 2″

E. Christensen et al., Web Services Description Language (WSDL) 1.1, (W3C) note, Mar. 2001; www.w3.org/TRwsdl

SOAP Version 1.2, World Wide Web Consortium (W3C) recommendation, June 2003; www.w3.org/TRsoap

Gomolski, B. (2006) Computerworld Opinion, Oct. 2006

Web Services Platform Architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging, and More

• ISBN13: 9780131488748
• Condition: USED – VERY GOOD
• Notes:

Product Description
“Other books claim to present the complete Web services platform architecture, but this is the first one I’ve seen that really does. The authors have been intimately involved in the creation of the architecture. Who better to write this book?” –Anne Thomas Manes, Vice President and Research Director, Burton Group “This is a very important book, providing a lot of technical detail and background that very few (if any) other books will be able to provide. The list of authors includes some of the top experts in the various specifications covered, and they have done an excellent job explaining the background motivation for and pertinent details of each specification. The benefit of their perspectives and collective expertise alone make the book worth reading.” –Eric Newcomer, CTO, IONA Technologies “Most Web services books barely cover the basics, but this book informs practitioners of the “real-world” Web services aspects that they need to know to build real applications. The authors are well-known technical leaders in the Web services community and they helped write the Web services specifications covered in this book.Anyone who wants to do serious Web services development should read this book. ” –Steve Vinoski, Chief Engineer, Product Innovation, IONA Technologies “There aren’t many books that are as ambitious as this one is. The most notable distinguishing factor of this book is that the authors have tried to pair down the specifications for the user and rather than focusing on competing specifications, they focus on complementary ones. Nearly every chapter provides a business justification and need for each feature discussed in the Web services stack. I would recommend this book to developers, integrators, and architects.” –Daniel Edgar, Systems Architect, Portland General Electric “Rarely does a project arrive with such a list of qualified and talented authors. The subject matter is timely and significant to the industry.” –Eric Newcomer, author of Understanding SOA with Web Services and Understanding Web Services and Chief Technology officer, IONA The Insider’s Guide to Building Breakthrough Services with Today’sNew Web Services Platform Using today’s new Web services platform, you can build services that are secure, reliable, efficient at handling transactions, and well suited to your evolving service-oriented architecture. What’s more, you can do all that without compromising the simplicity or interoperability that made Web services so attractive. Now, for the first time, the experts who helped define and architect this platform show you exactly how to make the most of it. Unlike other books, Web Services Platform Architecture covers the entire platform. The authors illuminate every specification that’s ready for practical use, covering messaging, metadata, security, discovery, quality of service, business-process modeling, and more. Drawing on realistic examples and case studies, they present a powerfully coherent view of how all these specifications fit together–and how to combine them to solve real-world problems.* Service orientation: Clarifying the business and technical value propositions * Web services messaging framework: Using SOAP and WS-Addressing to deliver Web services messages * WSDL: Documenting messages and supporting diverse message interactions * WS-Policy: Building services that specify their requirements and capabilities, and how to interface with them * UDDI: Aggregating metadata and making it easily available * WS-MetadataExchange: Bootstrapping efficient, customized communication between Web services * WS-Reliable Messaging: Ensuring message delivery across unreliable networks * Transactions: Defining reliable interactions with WS-Coordination, WS-AtomicTransaction, and WS-BusinessActivity * Security: Understanding the roles of WS-Security, WS-Trust, WS-SecureConversation, and WS-Federation * BPEL: Modeling and executing business processes as service compositions Web Services Platform Architecture gives you an insider’s view of the platform that will change the way you deliver applications. Whether you’re an architect, developer, technical manager, or consultant, you’ll find it indispensable.Sanjiva Weerawarana, research staff member for the component systems group at IBM Research, helps define and coordinate IBM’s Web services technical strategy and activities. A member of the Apache Software Foundation, he contributed to many specifications including the SOAP 1.1 and WSDL 1.1 specifications and built their first implementations. Francisco Curbera, IBM research staff member and component systems group manager, coauthored BPEL4WS, WS-Addressing, and other specifications. He represents IBM on the BPEL and Web Services Addressing working groups. Frank Leymann directs the Institute of Architecture of Application Systems at the University of Stuttgart. As an IBM distinguished engineer, he helped architect IBM’s middleware stack and define IBM’s On Demand Computing strategy. IBM Fellow Tony Storey has helped lead the development of many of IBM’s middleware, Web services, and grid computing products. IBM Fellow Donald F. Ferguson is chief architect and technical lead for IBM Software Group, and chairs IBM’s SWG Architecture Board. A(c) Copyright Pearson Education. All rights reserved.

Web Services Platform Architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging, and More