chris horn's blog

In my previous post, I discussed a key challenge facing executives, such as the real VP, K-san, who in principle wish to generate value by adopting SOA across their enterprise. I summarized how Lean Manufacturing and Lean Design gives Toyota the confidence to claim the tagline (here in Ireland at least!): “The best built cars in the World”. I also noted the emergence of Agile thinking in software development thinking.

SOA should impact an entire enterprise’s computing capability as well as business architecture, and needs to be more holistic than specific software development practices such as XP or Scrum. Lean principles can be applied to SOA, whether or not Lean and Agile techniques are also applied to the actual software development of services in SOA. While I personally advocate that software development should be agile and lean, some enterprises may chose not to do so whilst still nevertheless applying Lean thinking to their architecture. The macro principles do not necessarily imply micro ones. The focus of what I call Lean Software Services - LeSS - is empowering people within an organization to focus on their key responsibilities and opportunities, without being overwhelmed by technology choices.

SOA is more than just another technology fad. It is not an issue merely for the CIO: it impacts the CEO and the Board room. It fundamentally impacts the business architecture of an enterprise, as tasks and services undertaken both directly by humans (alone), machines (alone), and humans and machines (acting together), are composed into business choreographies. The composite processes which result are fundamentally different from the classical stove pipes and “silo-ed” applications which are sometimes found as a consequence of history and immediacy: specific business support is needed, specific applications are purchased or built to address these urgent requirements, and once operational these applications become valuable – if not critical – to business operations. Another cause of software silos is merger and acquisition activity, which sometimes result in businesses being urgently combined by operating two software business stacks side by side. It is not that unusual to see operators – for example in a call centre – using multiple physical screens to interact with entirely separate backend systems. SOA is fundamentally and dramatically different: it creates enterprise business value by horizontal impact across the entire business and IT architecture.

SOA embraces a number of software strategies:

· user interfaces, including both traditional screens and new (eg handheld) devices;

· the choreography of software services, and thus the composition of various business logic components to implement business process flows across the enterprise;

· software services, which are the software implementations of those business logic components;

· and finally the underlying substrate of hardware, operating software, databases and middleware.

Separate to each of these four strata, but having influence on all four of them, is the governance of the architecture. Governance decisions arise from both operational and executive concerns: they include for example variation of operational capacity, operational fail-over and backup policies, but also executive led audit trails, authentication policies, and authorization procedures.

In considering Lean principles and SOA, one of the key Lean strategies is the reduction and elimination of waste. Henry Ford introduced “dock to factory floor” inventory avoidance, in which incoming materials were not warehoused but used immediately on the production floor. Toyota subsequently adopted the practice as part of their Just In Time inventory policy. The Poppendiecks interpreted waste elimination in software development as the minimization of unreleased software: code in development, and not yet in production. Partially done work – whether in manufacturing or software development – represents sunk cost but as yet unrealized value.

The Poppendiecks advocate a policy of delaying commitment – postponing writing any software – until there is clear evidence of precisely what is needed. Fuzzy and uncertain requirements lead to wasted effort and probable “bloatware”. Folklore asserts that the Pareto Principle in general applies to software services: 80% of users use only the same set of 20% of the features of a software system, and that by implication 80% of the features are of marginal value. I personally am unaware of any specific research data that supports the folklore, but it’s a good attention grabber for any executive! Kent Beck and his colleagues in the XP world also advocate cautious commitment until customer expectations and “stories” are well understood.

Folklore also has it that the cost of changing a software program increases (exponentially) with time. Delaying commitment therefore appears to destroy value. Lean Design and Agile/XP on the contrary increase value by delaying commitment, benefiting from modern software technologies which have reduced the costs of change.

Consider a fully flexible airline ticket, allowing you to select any flight over the next month. It is more valuable, and costs more, than a fixed ticket for a specific flight. Think also of stock options: an option to buy or sell something in the future has value right now. Delaying commitment can create value, not destroy it: see the excellent paper by Hakan Erdogmus and John Favaro who apply financial option analysis – including Black-Scholes option valuation - to software development using XP.

Naturally, if you want full flexibility for an airline ticket, you go buy yourself an aircraft of your own. The longer the time you have before an option to do something (fly, buy a stock, develop a software program) lapses, the more valuable the option is: I guess that’s one reason private aircraft are so expensive.

Of course, in the same way that delaying a decision can improve the discounted cash flow (DCF) value of a software implementation, poor subsequent execution can destroy the value by delaying positive cash flow. The Poppendiecks conjunct delayed commitment with rapid execution: once a decision is actually (eventually) made, it is put into practice extremely quickly. It is no good having an expensive private aircraft if it is out of service when you eventually decide to use it.

Seems a bit of a digression from SOA, perhaps ? Bear with me. As I noted above, the focus of LeSS is empowering people in the organization to work on their key responsibilities and opportunities, without being overwhelmed by technology choices. The highest value comes from delaying a decision to the opportune time, and then executing immediately. And then, perhaps later on, making a new decision, and executing immediately.

In fact, the ultimate value results if the decision can be orthogonal to the environment it affects. That is, the decision can be taken at any time, and re-considered at any further time, without restriction from the environment. Your private aircraft should be available any time you want it. To quote from Wikipedia: “Orthogonality guarantees that modifying the technical effect produced by a component of a system neither creates nor propagates side effects to other components of the system. The emergent behaviour of a system consisting of components should be controlled strictly by formal definitions of its logic and not by side effects resulting from poor integration, i.e. non-orthogonal design of modules and interfaces. Orthogonality reduces testing and development time because it is easier to verify designs that neither cause side effects nor depend on them.” A classic example from hardware design is that any computer instruction can be applied to any memory location, without restriction.

A good architecture – particularly a SOA – meets or exceeds expectations for run-time stability and performance, while minimizing the investment – time, financial, and human – to create, modify and maintain it. Orthogonality is an excellent strategy.

As we reflect on the four SOA layers I mentioned above (user interface, choreography, software services, and substrate) together with governance, LeSS insists that all are mutually orthogonal, yielding a separation of concerns. If this is achieved, staff are empowered to focus on their key responsibilities and opportunities, without being overwhelmed by technology choices. Learning can be amplified without corruption or qualification arising from other layers. Decisions can be delayed until appropriate information is known for a specific activity – whether designing a new screen, building a new choreography routine, or implementing a new software service – and then executing quickly, without recourse to factors arising in orthogonal layers. Integrity can be strengthened by building testing, assertions and governance without risk of stress cracks being induced from adjacent layers. In summary, the principles of Lean Design as advocated by the Poppendiecks and others, can be applied to SOA.

It goes further. My VP friend, K-san, noted in my previous blog posting of his concern of the lack of a talent pool for SOA. In particular, what technologies and industry standards do software developers need to implement SOA components ? What skills should I train my staff for, and what skills should I hire against ? Using LeSS, the answer is that software developers coding business logic as software services can pretty much use whatever technology with which they are comfortable – C#, Java, C++, C, Ruby, even Cobol; along with, as appropriate to the selected technology, message definitions, copybooks or IDL. The choreography of the software services which they implement, and the infrastructure to support them, should be – and are, is a LeSS environment - orthogonal concerns.

These are bold claims. Can the SOA strata be orthogonal ?

Let us start on the user interface and choreography layers. The LeSS claim is that user interface specialists and choreographers should independently design and implement. User interface specialists focus on the ergonomics of screen layouts, devices and the human-machine interface. Their primary attention is ensuring efficient dialogue with the software infrastructure, and minimizing misunderstanding resulting from inadequate layouts, poorly designed graphics and inconsistent command activation. Choreographers are concerned with business process flows across a set of collaborating business logic components, implemented as software services. The routines which they design ensure that business procedures are safely implemented and, further, that these can be rapidly extended and modified as business needs dictate. The routines in turn are implemented by a business process engine, of which several alternatives exist – both open source and vendor produced. In practice, most business process engines, certainly of which I am aware, do not impact very much on the user interfaces offered by the software services which they choreograph. Orthogonality at this particular boundary does not appear an issue.

Business logic components implemented as software services frequently require user input and guidance, and present information. In SOA, can the user interface and software services strata also be orthogonal ? In practice, user interfaces designed for browser access today separate “look’n’feel” from actual dialogue, by using for example CSS. Indeed there is a trend to further separation of business logic implementation in SOA, from presentation and dialogue to end users, by new client side tools based on Ajax technology – for example “html scraping”, data mashups and personalized portals. These browser based tools are orthogonal to the enterprise software services with which they interact.

Let us move on. Choreography tools, such as business process engines, ensure appropriate process flows between specific software services implementing business logic. Each software service implements a prescribed interface encapsulating its functionality – indeed this is a primary motivation for SOA, as I noted in my previous post. Thus, so as to control the process flows across software services, a business process engine has to understand the interface definitions. This begins to get at the root cause of my VP friend K-san’s issue: what technology should be used for interface definitions ? Can the choreography and software service strata really be orthogonal ?

A similar issue arises at the boundary between the software services and the underlying enterprise substrate (of middleware, databases, operating systems and hardware): can these two strata also be orthogonal ? Programming language portability used to be a major issue a couple of decades ago: it arguably is not today, due to dynamic languages (such as Ruby and PHP), bytecode interpreters (eg for Java), and platform virtualization technologies (such as VMware and Xen). On the other hand, middleware substrates and software application programming are usually strongly mutually coupled, and are hardly ever orthogonal. Business logic is written to exploit a specific middleware technology, whether it be message definitions for MQ, Tibco Rendezvous or JMS; or FML for Tuxedo; or IDL for CORBA; copybooks for Cobol; or J2EE EJBs or .Net components and WSDL.

LeSS strongly argues that software developers writing business logic to implement software services should be able to do so regardless of specific middleware technologies. Of course, each software project does have to make some choice: a C# developer selects Windows and .Net for her substrate; a mainframe programmer selected Cobol, copybooks and CICS; and a Java developer perhaps 10 years later choses Linux and JMS. Different components may be implemented in different technologies, for reasons relating to history and/or skills availability. It is the role of the middleware substrate to allow such decisions to be independently made, concurrently and also across time.

Please note that I am not arguing for complete transparency of the distributed infrastructure to the software developer. I can recall certain research projects, and certain commercial products back in the early 90s – lets not name them for fear of embarrassment – advocating that any (fine-grained) software interface should be capable of remote invocation, so that a software program can be provisioned arbitrarily across a network of machines! Rather, LeSS asserts that each software service should explicitly identify (at least) one interface as available for use by other software services (regardless of their technology), and quite probably from a remote machine. However the technology – MQ message definitions, CORBA IDL, WSDL, whatever – chosen to do so, may vary from software service to software service.

Please note too that I am not advocating universal availability of all technologies across the entire substrate of SOA: for example, it does not make sense to make MQ and CORBA and JMS and Tuxedo available everywhere across the enterprise. Instead, using Lean principles, a specific technology should be made available only when and specifically where needed: just in time. In particular, making a specific technology available at the core of the system – for example in a central hub – may be a prime target for the (Lean principle of) eliminating waste. When software is available, but infrequently used, it may be an example of sunk cost and poorly realized value. LeSS advocates provisioning and installation of substrate software – e.g. a messaging system like JMS – only at those specific software services (end-points) which need it at this time.

What of the governance of a SOA system ? Lean Manufacturing systems pay extraordinary attention to ensure smooth flow across the factory infrastructure even in the face of fluctuating demand and micro-orders from customers. Resource hubs are in general a source of challenge and problems: de-centralisation and dynamic allocation are fruitful tactics to minimize contention and to anticipate demand waves. LeSS likewise emphasizes that software business logic should be orthogonal from dynamic provisioning of capacity and capability. In general, dependence on central software hubs (usually on dedicated servers) is a poor tactic, even more so if a source of sunk cost and poorly realized value.

Drivers of governance and substrate changes can be very many: for example, security policy improvements; fail-over enhancements; change in choice of messaging protocol so as to reduce cost; change in a data format so as to modernize and improve integration; and re-factoring of a service interface definition schema so as to improve re-use, add clarity and enhance development agility. Versioning of service interfaces is common in the evolution of practical SOA implementations. Such policy enhancements in the governance, and improvements to operation of the enterprise substrate, should not require human intervention in the business software.

My friend K-san was concerned about the lack of skills for SOA: the technology choices available overwhelm a clear selection across the enterprise, leading to risk in staff selection and skill sets. LeSS empowers staff in the organization to focus on their key responsibilities and opportunities, without being overwhelmed by technology choices. Each project team can chose to use the technology with which they are most familiar. Separation of concerns, and orthogonality, can be achieved – today - by appropriate selection of off the shelf products.

Lean principles are being applied by many software development teams worldwide to eliminate waste, delay decision making until facts emerge, execute fast, make integrity inherent, amplify learning, empower teams and drive a holistic view of their system.

Lean principles can also be applied at the macro-level, to entire enterprise architectures. Learning can be amplified without corruption or qualification arising from other layers. Decisions can be delayed until appropriate information is known for a specific activity – whether designing a new screen, building a new choreography routine, or implementing a new software service – and then executing quickly, without recourse to factors arising in orthogonal layers. Integrity can be strengthened by building testing, assertions and governance without risk of stress cracks being induced from adjacent layers. The principles of Lean Design as advocated by the Poppendiecks and others, can be applied to SOA.

Separation of concerns, supported by technology which enables orthogonal decision making, and just in time commitment, is the key to Lean Software Services. In adopting SOA, ensure your chosen supplier or vendors provide you with orthogonal, just in time choices throughout the entire architecture. Then empower your teams to use technology with which they are familiar.