Blogs from the π4 Technologies Foundation

SOA Manifesto rambilings part 4 (what else?)

steve@pi4tech.com (Steve Ross-Talbot) — Thu, 03 Dec 2009 14:12:00 +0000

The Manifesto does not tackle any relationship between PROCESS ORIENTATION and SERVICE ORIENTATION. In this blog I'll tackle this link and explain why they go hand in hand. The only reason this was not done in the context of the Manifesto was time and focus.

So here is my take on why it is in fact important and perhaps one of the most important aspects to SERVICE ORIENTATION and SERVICE ORIENTATED ARCHITECTURE.

PROCESS ORIENTATION is a paradigm that constrains a solution to focus on the underlying flows between components where a component maybe a person or an agent for a person (e.g. a portal) or a software component (which maybe embodied by a SERVICE CONTRACT).

BUSINESS PROCESS MANAGEMENT (BPM) is the management of PROCESSES that are formulated by applying PROCESS ORIENTATION. A BUSINESS PROCESS MANAGEMENT SYSTEM is a software platform that supports the construction of PROCESS DESCRIPTIONS, their simulation, execution and life-cycle management.

ORCHESTRATION (as embodied by WS-BPEL) is a mechanism for describing, simulating and executing COMPOSITE SERVICES which are “orchestrated” by means of a some flow between them to deliver a new SERVICE.

Today BPM and ORCHESTRATION are common bed-fellows. Many companies use the former to deliver the person based workflows and the latter for composing complementary SERVICES, which may then be consumed by a BPM layer. In the future these two bed-fellows will merge with the introduction of WS-HumanTask and Bpel4People. These two related standards will deliver the necessary descriptions to enable both BPM and ORCHESTRATION to be merged.

When we think of BPM and SERVICE ORIENTED ARCHITECTURE we need to understand where things are today and where they may be tomorrow and deal with the present and plan for the future. Typically a BPM SERVICE ORIENTED ARCHITECTURE approach focuses on the encoding of PROCESSES at the business level so that legacy applications involved in the PROCESS are SERVICE ENABLED along the way. The reason to do the SERVICE ENABLEMENT is that it is a cheaper and faster route to leveraging legacy application within an overall BPM context. This is the case because of the huge technology investment in tools to SERVICE ENABLE and in BPM to leveraging SERVICES.

Successful BPM and SERVICE ORIENTED ARCHITECTURE projects (together or separately) are all dominated by a clear view of business value to be delivered. They are often preceded by a Proof of Concept which is constrained and focuses on key integration aspects (for SERVICE ENABLEMENT) and key PROCESS aspects (which manifest business value).

Key to business value is the identification of value based on a clear understanding of the vision and mission of an enterprise coupled with strategic goals. This is the case because the strategic goals, which are derived from the vision and mission, provide clear guidance as to where the value lies. Identification of the strategic goals and the Key Performance Indicators that go with them enables a project to be framed that has clear business value and so when delivered can be measured to determine the value delivered. The same Key Performance Indicators and their derivatives may then be used to monitor and measure the running PROCESSES and their attendant SERVICES and the delivered flexibility provides the means by which the solution can be tuned and adjusted. This ensures that the run-time governance of the solution always aligns the solution to the business goals through their expression in the Key Performance Indicators.

SOA Manifesto rambilings part 3 (the principles)

steve@pi4tech.com (Steve Ross-Talbot) — Mon, 30 Nov 2009 09:23:00 +0000

Principles

The principles are high level principles. They do not deal with design or organizational issues but may allude to them. They are part of the manifesto because they act as a guide in how one should approach SERVICE ORIENTATION and how one should apply the principles of SERVICE ORIENTATION. Following these principles will help to ensure that whatever gets delivered provides the necessary short and long term business value to justify its existence.

“Respect the social and power structure of the organization.”

At an enterprise level SERVICE ORIENTATION and a SERVICE ORIENTED ARCHITECTURE provide a more open mechanism for accessing capabilities through their SERVICE CONTRACTS. It makes it easier to reuse existing SERVICES and create new ones in line with business needs. What is very important in looking at this from an enterprise perspective is who owns the SERVICE, who has the budget and how do we cost account for the use of a SERVICE. Respecting the social and power structures of an organization is critical in understanding the economic effect of a SERVICE, how it is used and how it can continue to be used over time. Aligning budgets for SERVICES and aligning the use of SERVICES to some cost accounting mechanism requires that budgets are aligned to the power structures and that the SERVICE is cost accounted for, based on the social and economic power structures within an organization. Getting this wrong can result in SERVICE degradation over time as more people use it and budgets for its subsequent maintenance and operational use fail to reflect it use and importance.

“Recognize that SERVICE ORIENTED ARCHITECTURE ultimately demands change on many levels.”

This is a corollary of the previous principle. Adopting SERVICE ORIENTATION and implementing and using a SERVICE ORIENTED ARCHITECTURE requires alignment through the organization. SERVICES are used, SERVICES change, and SERVICES are composed, all of this can happen across the entire organization. Use happens from all parts of the organization, request to change comes from all parts of the organization and composition of new SERVICES may happen anywhere in the organization and may use SERVICES from other parts of the organization. This is why SERVICE ORIENTED ARCHITECTURE demands change at many levels. The capabilities that SERVICES expose become un-siloed and that makes them enterprise assets and not just assets for one business unit. This democratization of capability requires change on all levels of an organization as users express future desires driven by changing needs and as the implementation of a SERVICE ORIENTED ARCHITECTURE makes flexibility easier to achieve.

“The scope of SERVICE ORIENTED ARCHITECTURE adoption can vary. Keep efforts manageable and within meaningful boundaries.”

This is a principle derived from the Evolutionary value statement. It is far better to aspire to the benefits of a SERVICE ORIENTED ARCHITECTURE but realize them incrementally. Typically one might start with the portalisation (portal-led SOA) of some business unit and SERVICE ENABLE along the way. The additional cost for SERVICE ENABLEMENT is mitigated by a standards based approach to the integration of the underlying capabilities with the needs of the portalisation. What we see in Cognizant is that this approach is complemented by additional concurrent but offset projects that then seek to further SERVICE ENABLE along the way as the portalisation efforts move to another business unit. Portalisation is not the only way to start. One might have specific needs to reuse components or applications simply to make available data and process from several application but to do so in a more flexible way. SERVICE ORIENTED ARCHITECTURE adoption starts by making it manageable within meaningful boundaries and so can be effectively measured in terms of the business value that it yields. Never forget Return on Investment, it pushes and pulls development.

“Products and standards alone will neither give you SERVICE ORIENTED ARCHITECTURE nor apply the SERVICE ORIENTATION paradigm for you.”

Products and standards do not apply SERVICE ORIENTATION to deliver a SERVICE ORIENTED ARCHITECTURE but they may help. It is people who wield them, making sure you have the right skills to get the most out of a SERVICE ORIENTATION approach and get the most out of a SERVICE ORIENTED ARCHITECTURE is a key aspect of any SERVICE ORIENTED ARCHITECTURE program regardless of how it is constructed or the boundaries in which it fits. In Cognizant we specialize in matching the right resources to achieve a positive outcome and the role of the Enterprise Architect becomes a key to ensuring that all of the moving parts of the Software Development Lifecyle (SDLC) work together.

“SERVICE ORIENTED ARCHITECTURE can be realized through a variety of technologies and standards.”

A SERVICE ORIENTED ARCHITECTURE does not have to rely on an ESB, WSDL, BPEL or any other standard or technology. The key aspects of SERVICE ORIENTATION and SERVICE ORIENTED ARCHITECTURE are the descriptions that we call SERVICE CONTRACTS and the decoupling of them from the implementation of their capabilities at both design and runtime. An instance of an SERVICE ORIENTED ARCHITECTURE may use asynchronous messaging and pass documents between SERVICES. An instance may use WSDL invocations with some form of remote procedure call. An instance may use BPEL and it may use business rules. In all cases the de-coupling should be self evident. A yard stick for an instance of a SERVICE ORIENTED ARCHITECTURE is to locate a SERVICE REPOSITORY, because without one, de-coupling invocation on a SERVICE CONTRACT from a SERVICE IMPLEMENTATION becomes impossible to achieve in any uniform way.

“Establish a uniform set of enterprise standards and policies based on industry, de facto, and community standards.”

A bit of motherhood and apple pie but something that the can certainly catch you if you don’t do it. Establishing a uniform set of enterprise standards and policies can reduce the risk of mis-delivery of a solution. Where there are industry standards they often leverage XML as a means of encoding information and it is better to use them than not. It can cut down integration costs and reduce the time it takes to deliver an enterprise information model as well as the processes that manage that information. The enterprise standards should cover all aspects of governance and should support rapid change. The policies should guide security choices, transactions, and service levels. One key relationship between a SERVICE ORIENTED ARCHITECTURE and this principle is that many industry and de-facto standards are seeking to use the same SERVICE ORIENTED approach to describing the processes that underpin standards, this is true in International Standards Organization, the International Swaps and Derivatives Association, Healthcare Level 7 and many others. For those SERIVICES that are outward facing this may mean that the SERVICE CONTRACTS are already defined which can help reduce the cost of external connectivity and provide cross enterprise interoperability.

“Pursue uniformity on the outside while allowing diversity on the inside.”

This is a cry for SERVICE CONTRACTS and process uniformity on the boundaries of the enterprise and diversity as to how you achieve implementation on the inside. SERVICE CONTRACTS mandate a degree of uniformity. We can go further by publishing our external boundaries in terms of the SERVICE CONTRACTS we wish other to see and the ordering rules over those contracts that make up the processes that we wish to make visible. In so doing we ensure a higher degree of interoperability.

“Identify services through collaboration with business and technology stake-holders.”

From a technology platform perspective it is important to identify core TECHNOLOGY SERVICES. These will have the highest reuse rating and you can only do this by understanding the technical requirements from the technology stake-holders. Likewise the only way to gain reuse at the business level for BUSINESS SERVICES is to do it with the business stake-holders. The widest collaboration, across business units will yield the widest reuse, even if you have a single project, it is worth gathering requirements from a wider set of stockholders so that you can plan effective reuse and change management over time. Hence “Recognize that SERVICE ORIENTED ARCHITECTURE ultimately demands change on many levels” and “Identify services through collaboration with business and technology stake-holders” are complementary.

“Maximize SERVICE usage by considering the current and future scope of utilization.”

Wider collaboration for effective SERVICE IDENTIFICATION is part of the process of understanding the usage of both current and future SERVICES and their utilization. Don’t just look at the functional aspects because the scalability will be compromised as usage rises. Taking into account the scalability issues mitigates the risk of retrenchment and ultimately failure of large scale enterprise adoption.

“Verify that SERVICES satisfy business requirements and goals.”

This principle may well seem obvious, but it has profound consequences. One of the things that SERVICE ORIENTATION and SERVICE ORIENTED ARCHITECTURE instances provide is a clean separation of SERVICE CONTRACTS from SERVICE IMPLEMENTATION. It matters not if you use WSDL to do this or SOAML or Abstract BPEL, what is important is that before a SERVICE is constructed (implemented) we can, at worst, manually check that the collection of SERVICE CONTRACTS match the requirements that gave rise to them. If these requirements are themselves derived from higher level business requirements we can check the derivation. And if the higher level business requirements are derived from business goals we can check their alignment too.

When we do this manually, and most good SERVICE ORIENTED ARCHITECTURE practitioner do exactly this, we call it SERVICE ORIENTED ARCHITECTURE GOVERNANCE and it is part of Enterprise Architecture Governance. It is part of the enterprise alignment process that is done manually.

Given that SERVICE CONTRACTS can be properly described in a formal and structured way (i.e. WSDL , SOAML and Abstract BPEL) and given that we can encode the requirements that give rise to these SERVICE CONTRACTS, it would make a lot of sense to get computers to check the SERVICE REQUIREMENTS against SERVICE CONTRACTS and automatically show that the "SERVICES satisfy their business requirements". We are not suggesting at this point that we can do the "satisfiability" test through the different levels of requirements or indeed the business requirements against the business goals - although even this is possible. What we are suggesting is that the immediate requirements (SERVICE REQUIREMENTS) that give rise to the SERVICE CONTRACTS can be automatically checked to show that the SERVICES meet their SERVICE REQUIREMENTS.

This is what T estable Architecture is all about and the wider "satisfiability" is what Savara will deliver over time.

“Evolve services and their organization in response to real use.”

Accept that we live with imperfection but strive to attain it. Accept that things change. In this way we can focus on evolution to ensure that SERVICES meet their business requirements as those same requirements evolve over time. Equally we may choose to re-organize services for the same reasons. We may choose to uncouple a composite or to change it to reflect changes to real use. The best user interfaces are always tested by users and Apple have been very much the masters of getting it right. Doing the same for SERVICES from the top down, the middle out and the bottom up by evaluating their use in real situations will reveal improvements on design, improvements to requirements and manifest improvements with continual alignment to business requirements and goals.

“Separate the different aspects of a system that change at different rates.”

Engineering for change is not easy. It requires an understanding of what is needed today against what might be needed tomorrow. A key metric is how executive management and in turn their immediate management team steer the ship. What are the controls and the points of change that they need to do their job. Understanding industry influences and trends on an enterprise and understanding the vision provide a way of scoping what needs to be made flexible in the future. Understanding the mission and strategic goals provide a scoping of the changes needed in the near term. Having effective change management procedures in place and effective change request processes are imperative to continual improvement.

Another key aspect of rates of change is that processes change infrequently, but they do change, but the decision point, we might think of them as business rules, change far more frequently. Hence outboarding business rules and using a BUSINESS RULES SERVICE is an important architectural pattern which complements outboarding of processes through orchestration and workflow.

Don’t think that what you deliver will not change or is optimal. Let the users use and make suggestions. If you get flexibility engineered in from the start then the cost of suggested change will reduce and the ability of the enterprise to optimize how it does things increases.

“Reduce implicit dependencies and publish all external dependencies to increase robustness and reduce the impact of change.”

When we create COMPOSITE SERVICES, just like when we create views in a database, it is important to understand the SERVICES that they derive from. Without documenting and making these dependencies clear we potentially run into huge change management and governance problems. It should be standard best practice to publish the key dependencies both in terms of the services that may be used and the underlying technology dependencies too. Such dependencies should be documented and published as some form of attachment to services in the SERVICE REPOSITORY.

“At every level of abstraction, organize each service around a cohesive and manageable unit of functionality.”

Good design coalesces concepts into some form of cohesion. This is true for any piece of software that is constructed. SERVICES are no different in this regard and at each level of abstraction be it a BUSINESS SERVICE, a TECHNICAL SERVICE or a DATA SERVICE the principle of cohesion applies. Organizing and making things manageable takes effort and discipline but the rewards are often greater use and reuse because the focus of the SERVICE becomes clear and the concepts coalesce to deliver appropriate functionality for the level of abstraction.

SOA Manifesto rambilings part 2 (the value statements)

steve@pi4tech.com (Steve Ross-Talbot) — Mon, 16 Nov 2009 23:08:00 +0000

The value statements reflect a desired prioritization of one value over another. It does not mean that the value that has a lower priority is not important it just means that the value with higher priority is seen as more important. The value statements are there to help prioritize key decisions. For example having a technical strategy with no business value makes little sense. But a technical strategy to support business value makes huge sense. Equally having project specific goals make sense but not at the cost of strategic goals. Should the need arise to support project specific goals over strategic goals then the decisions should be made with our eyes wide open.

“Business value over technical strategy”

SO and SOA is not about technology. One may use technology to deliver it. The value is the value that the business identifies or agrees to. In the world of Enterprise Architecture and Solutions Architecture we measure the outcome of deliverables against agreed business expectations. The technical strategy that is employed is created based upon what we need to focus on technically to deliver business value. Many projects fail because they loose sight of the alignment with business imperative. Ensuring alignment to business value is the key to good governance.

“Strategic goals over project-specific benefits”

In the world of effective Enterprise Architecture applied to a business landscape, we seek to understand the vision of the enterprise and we seek to understand the mission statement. The vision is aspirational and forward looking, the mission is actionable and focused on the immediacy of the enterprise. The vision and mission are used to frame strategic goals for the enterprise. The strategic goals might be implemented by one or more programs of work within the IT space of an enterprise. These programs might incorporate many projects. One of the roles of an Enterprise Architect is to ensure that the programs align to the strategic goals and that the projects reflect them. Without the transparency and traceability of strategic goals to the vision and mission, projects cannot expect to deliver against them. Drift is a common concern and when siloed projects drift away from the strategic goals and focus on short term issues at the expense of the bigger picture. The result is a more costly solution as it has to be re-factored and/or re-built sooner than was anticipated because it failed to meet the strategic goals.

“Intrinsic interoperability over custom integration”

The easier and faster it is to compose new capabilities the more cost effective IT becomes in supporting the business and its changing needs. If we always have to place a mediator between services to reuse them then we are falling into the trap of custom integration and what this tells us is that the design of our services does not support intrinsic interoperability. From a principle perspective, moving to a more document centric approach encourages greater interoperability but compromises the ease of use or understanding of a service's capabilities. Probably no where else in designing services is it more important to get the functions and the types of the parameters correct and indeed to be unafraid of re-factoring over time to move towards greater intrinsic interoperability.

“Shared services over specific-purpose implementations”

The granularity of services in an implementation of an instance of a SOA is a common cause for concern. Reuse and therefore the sharing of capabilities through the embodiment of services and their contracts seems to be much harder than anticipated. Several methodologies have been espoused to help. What we all know instinctvely is it is never a good idea to re-develop the wheel. But of course we constantly re-develop the car. Cars are created through the composition of many existing components. The new Beetle makes use of the Golf chassis, but it feels like a very different car. Services as components for the construction of new capabilities is a key principle of SO but doing it is harder that saying it. What is needed is good component repositories with good documentation and reviews. Back in the 1980’s Shlaer and Mellor had the same idea but expressed it as a book of components, like those that electrical/electronic engineers might use, for things we use to create new capabilities. Sometimes a customer implementation is needed but it is not that often and measurements of customer implementation vs reuse should always be made on a regular basis to ensure that the benefits of shared services are being realised.

“Flexibility over optimization”

There is an old software proverb that rings true. Make it work before making it fast. Making things flexible, choosing where the points of flexibility need to be is not easy but by following some simple principles we can at least move much of what is needed outside of code making services configurable. Business rules can be used in place of coded logic, orchestration can be used in place of hardwired configuration. A heuristic approach that might be in a document for service implementers would be to ensure that business rules and processes stated in requirements are exposed to enable them to be changed.

“Evolutionary refinement over pursuit of initial perfection”

The old adage of don’t try to boil the ocean comes to mind. We always seek perfection but we always need to temper it with the realisation that perfection is a focus not a goal. Good software projects and programs are phased. Occasionally we have the big bang approach but they rarely succeed. So we need to be mindful that we cannot do it all in one go and so phase the approach. It is common for many SO projects and programs to be led by the user interface inwards. Service enabling as you go is a better approach than trying to service enable and then figure out how users interact with the service. This is the case because without the users we cannot be sure of the pain point the wishes and desires of those users and so cannot address their concerns. And it is the users (customers) that matter.

SOA Manifesto ramblings and observations PART 1

steve@pi4tech.com (Steve Ross-Talbot) — Thu, 05 Nov 2009 11:54:00 +0000

It has been a couple of week at least since we published the SOA Manifesto. Alas I have rather busy putting some of it into practice. But that is done now. So time to elaborate further.

I plan to break this blog into 3 parts to provide some clarifications, some observations and some personal opinions about the SOA Manifesto. In this blog I want to deal with three specific points in the SOA Manifesto. In the next two blog I will deal with much of the rest of the SOA Manifesto.

The three specific points relate to the following:

"Service orientation is a paradigm that frames what you do. Service-oriented architecture (SOA) is a type of architecture that results from applying service orientation."

"Business value over technical strategy"

"Verify that services satisfy business requirements and goals."

"Service orientation is a paradigm that frames what you do. Service-oriented architecture (SOA) is a type of architecture that results from applying service orientation."
I have, for a very long time, challenged the wisdom of the term Service Oriented Architecture. If you track back over the last 5-6 years the term SOA has been used and misused almost on a daily basis. Vendors have often hijacked the term claiming that they sell SOA.

The term Service Orientation is the antecedent to SOA. You cannot have anything being a SOA if you didn't do some sort of SO, just as you cannot have an Object Oriented Architecture or implementation of one without practicing OO.

Clearly we can use C++ in an non-OO way. We can use C in a non-OO way, but oddly enough we can also use it in an OO-way. X-Windows was a great exemplar of an OOA that was done by using OO within a C based implementation. If we constrain things and use a classic OO language, like Smalltalk, then by definition you end up with an OOA.

Thus the terms OOA and SOA are types of things not instances. There may be many instances of an OOA and many of a SOA. Therefore we can use the phrase "my implementation of a distributed system is an instance of a SOA", and we can also say that "my implementation was created by applying the principles of SO". Hence SO is something you do and an instance of a SOA is something that you might create through the application of SO principles.

Why is this important? Isn't it obvious? For those that are SO practitioners it is obvious, but we are faced with myth that has dogged the rise of SOA. I have many customers who ask how do I sell SOA? It is not something that you sell because you cannot buy it. So we need clarity and common language so that when we engage with customers we do not add to the confusion but rather remove it and provide clarity. So obvious to us practitioners yes, and important YES, so that we can effectively engage with businessES who have need of business benefits that a SO approach can deliver through Service Enablement to provide an instance of a SOA within a business context.

"Business value over technical strategy"
Providing a business context is all important. In the dot-com boom days many projects were technology led and the business benefits unclear. Most if not all failed as a result. Motherhood and apple pie comes in here. It is common sense that we understand the business value prior to any technical strategy. The technical strategy supports the business value. Technical strategy is there to support the vision, mission and strategic goals that a business sets for itself. The technical and application roadmaps are constructed to do exactly this. The funny thing about "common sense" is that it is not common, and that is why we needed to state this value proposition business value over technical strategy.

"Verify that services satisfy business requirements and goals."
This principle may well seem obvious too. But it has profound consequences. One of the things that SO and SOA instances provide is a clean separation of Service Capability (Contract) from Service Implementation. It matters not if you use WSDL to do this or SOAML or Abstract BPEL. The important thing here is that before a service is constructed (implemented) we can, at worst, manually check that the collection of Service Capabilities match the requirements that gave rise to them. If these requirements are themselves derived from higher level business requirements we can check the derivation. And if the higher level business requirements are derived from business goals we can check their alignment too.

When we do this manually, and most good SOA practitioner do exactly this, we call it SOA governance and we call it Architecture Governance (although governance is actually wider than this). It is part of the alignment process that is done manually.

Given that Service Capabilities can be properly described in a formal and structured way (WSDL , SOAML and Abstract BPEL all do this) and given that we can encode the requirements that give rise to these Service Capabilities - I shall call them Service Requirements - it would make a lot of sense to get computers to check service requirements against service capabilities and automatically show that the "service satisfy business requirements". I'm not suggesting at this point that we can do the "satisfiability" test through different levels of requirements or indeed the business requirements against the business goals - although even this is possible. What I am suggesting is that the immediate requirements that give rise to the Service Capabilities can be automatically checked to show that the Service Capabilities meet the Service Requirements.

This oddly enough is what Testable Architecture is all about and the wider "satisfiability" is what Savara will deliver over time.

The SOA Manifesto

steve@pi4tech.com (Steve Ross-Talbot) — Sun, 25 Oct 2009 21:35:00 +0000

Well we did it. We sat down for the best part of 3 days and turned around an SOA Manifesto. I shall blog further, as will my fellow signatories, but for now here are all of the authors blogs to make it easier for you to see what they have to say over and above the SOA Manifesto and of course for you to contribute too.

It is very flattering that the press have used the term "Industry Visionaries" to collectively name us. But we are really no different to many of you practitioners out there. What will make the SOA Manifesto valuable is use and feedback to hone it over time. So take a look comment away and keep us all in the loop. We shall be looking.....

The movie of the announcement is also available.

Cheers

Steve T

In no particular order ....

Anne Thomas Manes
Stefan Tilkov
Dave Chappell
Brian Loesgen
Paul Brown
Mark Little
John deVadoss
Clemens Utschig-Utschig
Joe McKendrick Analyst
Ali Arsanjani

The others I shall add when I have their coordinated.

More on the SOA Manifesto

steve@pi4tech.com (Steve Ross-Talbot) — Thu, 15 Oct 2009 14:45:00 +0000

I have been thinking ever more about the SOA Manifesto. In part fuelled by the proximity of the WG meeting and in part by comments that have been made.

I take on board the comments on the need for "boldness" I have never been shy about dealing with that. But we need to ensure that the manifesto has use today that is practical and very business focused - something I have picked up from the many comments made at infoQ. And we need to map out what is missing and look deeper into a brave new world that builds upon our current available SOA platforms and methods of constructing solutions.

One thing stands out for me on the practical usage side and one on the future.

On the practical side:

The use of Service Orientation is underpinned by delivering continuous business value. Business value MUST always be aligned to business goals and needs.

In the future:

It MUST be possible to express the information model(s), the static service model and the dynamic model of service collaboration such that the first describes the data needs of services, the second describes the service usage across peers of a specific service and the third describes the common collaborative behavior of peers collectively. All of which MUST be founded upon one or more business requirements.

I think these two and refinements of them will stand us in good stead. The devil is always in the detail.

The former is really motherhood and apple pie. Easy to say but how do we bake it?

The latter is more of challenge because it requires a better understanding of what underpins a distributed system in terms of behavior and information that drives that behavior and these, at the end of the day, are complex mathematical topics. We must be careful and ensure that we do not go into too much detail but provide the right syntactic sugar that allows formalism to deliver to us in a way that we can all understand and use.

Let us not forget that without mathematics we would have no computing. In fact without it we would have no engineering. They are all based on mathematics but we rarely see the models that are used to underpin engineering but in the case of computing we use those models all the time. They have syntactic sugar we call them programming languages.

An Architecture Manifesto

steve@pi4tech.com (Steve Ross-Talbot) — Tue, 29 Sep 2009 10:28:00 +0000

Way back in 2004 a good friend of mine, Alexis Richardson, decided to convene a summit of architects. The summary of the event is below:

The Architects Summit is a one off event challenging a group of pragmatic and active technologists to formulate, document and publish a consensus view on requirements and best practice for software application platforms and development tools.

I cannot remember now how many turned up but it was well attended and amongst the participant Chris Swan and Hugh Grant were there, Rod Johnson was there, Matthew Rawlings, John Davies, Cameron Purdy and many others.

I was asked to co-chair with Alexis, presumably because chairing seems to be my thing amongst a diverse set of individuals and opinion.

The net result was certainly a stimulating debate but no manifesto was ever issued because we could not get agreement. In part this was because the camps divided into classic enterprise architects and guru-status technical architects. And never the twain can agree.

However, given the fashion for manifesto’s here is my own personal one which was done at that time and to which I still pretty well subscribe to.

The SOA Manifesto

steve@pi4tech.com (Steve Ross-Talbot) — Tue, 22 Sep 2009 15:30:00 +0000

I was recently invited to participate in the SOA Manifesto. It is huge honour and from the list of participants involved I would expect nothing less than a really focussed and helpful manifesto.

Manifesto's a a bit of craze these days. I noticed that there manifesto for cloud and for internet and so on. But oddly enough nothing for SOA.

As a participant I started to look into what is out there and I must admit I am really surprised at how little there is for SOA. Of course we have patterns and principles and even governance [1, 2] for SOA but as yet no one has written a manifesto personal or otherwise to share with the industry as a whole.

In arriving at some manifesto for SOA which will help focus people on the key aspects of what service-orientation means and what in means to have a service-oriented-architecture there are some key areas that need work.

First an foremost we need to ensure that executive sponsors across industries understand what it means to them. Inevitably they need to know what is the effect on the top line revenus and the bottom line costs. Equally they need to understand business model consideration in adopting a service-oriented approach. Whilst we would all like to offer thing free, offer it immediately and offer it so that it is perfect in every way we have to be realistic that software costs money, takes time and is rarely perfect. So ensuring that these apsects of the software development lifecycle (SDLC) are effectively articulated to business sponsors will help them make decisions.

Secondly we very much need to serve our own IT community. We need to arrive at some consensus that helps people understand what service-orientation really means, its guiding principles, and what consititutes a service-oriented-architecture. Now these may all seem obvious to some of you. But let me assure you that in my world I often have to deal with people who equate WS-* to SOA and equate ESB to SOA. Which of course is not the case. They may help and even constrain and SOA but they not make one.

So we have our work cut out. We also need to deal with the future and what that might entail and help to direct and give it impetus.

So watch this space. The manifesto is due out soon enough. And I for one am looking forward to it let alone having the honour of helping to fashion it.

Savara

steve@pi4tech.com (Steve Ross-Talbot) — Sat, 05 Sep 2009 14:33:00 +0000

JBoss Community Launches Savara Project.

I guess it has been coming for sometime given the blog entries from both myself and Mark Little. Finally we have launched Savara. It is an open source community project the aim of which is to deliver to the open source user community and other interested parties a set of tools for developing end to end service oriented solutions (in the first instance) and general distributed solutions (in the second). It will embody Testable Architecture but much more. The key aim is to develop not just tooling but also methodologies to support its use that will focus upon the testabilility of artefacts at different levels of refinement to ensure provable alignment or correctness.

We expect this initiative to change the way in which we gather requirements, fashion solutions and deliver them as well as manage changes over time. And we expect to move ever closer to our (unattainable aim) of deliver it now, deliver it free and deliver it correctly which will remain our mantra to keep us focused.

The vision is broad, the time scales potentially long but we do expect benefits to be provided early and on a continual basis.

I am sure with Gary Brown (Red Hat) and Bhavish Kumar (Cognizant) co-chairing the initiative we can expect great results.

Take a look when you can and get involved regardless of you affiliation.

Testable Architecture and Agile Development

steve@pi4tech.com (Steve Ross-Talbot) — Sat, 04 Jul 2009 11:36:00 +0000

I was watching and listening to Dan North and Michael Feathers on the web. It is worth a look. At about 12 minutes Dan says the following "You can TBD your way out of anything... There is balance between doing all up front design and doing no up front anything which is irresponsible." and he mentions that Richard Watt says "Enough up-front thinking" is what you need.

The tension between agile and "enough up front thinking" is what I want to explore. Those agile bigots that think you should not do anything up front miss the point. Hopefully there are not too many of them. Having deployed "testable architecture" in several sites now I do get asked how does this work with agile. And I think Dan and Michael have really nailed it.

What is enough?

The communication/interaction model between services in an SOA is probably a good place to start. The aim is to provide enough structure without getting in the face of developers who will operate in an agile process. If testable architecture, embodied today in the pi4soa tools, provides the necessary communication/interaction model along with the necessary minimum data structures (for example the business transaction identities needed to support the communication model and any asserted state thereafter) then we can (and we have in Cognizant) use it to provide "what is enough" and thereafter engage developers in an agile process to fill in the gaps. The structure is preserved and testable against requirements, as I have often said in my other posts. And in more recent posts that structure remains a valuable testable artefact for systems integration testing.

Defect Detection in Systems Integration Testing

steve@pi4tech.com (Steve Ross-Talbot) — Thu, 18 Jun 2009 07:53:00 +0000

Another short movie to illustrate a point. This time I want to move to the left brain side of the testable architecture methodology and deal with the issues that confront many of us on complex programmes.

The issue is one of defect detection, and I want to specifically highlight how we can use testable architecture in its current form (aka WS-CDL and the pi4soa tool-suite) to detect a system defect. The defect is categorised by a variation in the system wide (and so end-point specific) contract for the services. In this case we change the contract and update one of the services but not the other. It is a pretty typical problem that is hard to identify (although not impossible) during systems integration testing. What we do here is use the monitoring capabilities during the system integration testing to determine the root cause of the problem.

It is only but a short jump from here to full run time governance. And that is what Overlord is all about.

Enjoy.

Global Models

steve@pi4tech.com (Steve Ross-Talbot) — Thu, 28 May 2009 09:14:00 +0000

Perhaps the biggest contribution that the Choreography Working Group has made, along with our academic colleagues and colleagues from many vertical standards organisations, is the formulation of a global model. WS-CDL was the first attempt at codifying such a model.

BPMN2 when it is finally released will have done us a huge service if, as we expect, it combines both global and local behaviors. The lack of a local model for behavior has long been a gap in our thinking on global models and would add the refinement needed to go from very high level to executable artefacts in a controlled and refined way.

So it was great to see the blog at Overlord that welcomes BPMN2 to the world.

16 Minutes on Testable Architecture

steve@pi4tech.com (Steve Ross-Talbot) — Wed, 22 Apr 2009 21:25:00 +0000

Using formal methods to support an offshore global delivery method

steve@pi4tech.com (Steve Ross-Talbot) — Sun, 15 Feb 2009 19:42:00 +0000

I have blogged before on this topic but now I want to share some of the results with you.

I was recently involved in two insurance focused system integration initiatives. The fact that they were in insurance is more suggestive that the same approach can work anywhere as insurance tends to be fairly conservative when it comes to new technology.

The background, in both cases, was an in-flight SOA-road map that was being executed. The road map required integration of legacy applications and portal development to support a user experience. A classic ESB approach was used to manage integration and provide both mapping from and to a legacy message format and mediate between the new functionality and the old legacy system. For the most part this is straight forward, or at least so it seems. Estimates were given for the two initiatives to provide the necessary technical contract that would drive implementation offshore.

In the first instance the allotted time to develop a solution and provide the technical contracts was of the order of 15 days effort. This would involve gathering requirements, functional and non-functional, looking at message formats to support the data model, understanding the business transactions so that the solution could be effectively monitored, delivering service contracts for the mapper and mediator services, providing state diagrams to show the individual service behaviors needed and sequence diagrams to provide a collaboration context. The total number of services was 4 including the client, the mediator, mapper and legacy service.

In the second instance the allotted time to develop a solution was of the order of 60 days of effort. In this case there were many more services (I prefer to call them roles) that needed to be understood and many more interactions between those roles. The same level of technical contracts was required to be delivered over the 8 or so roles.

In both cases we used testable architecture. We gathered the requirements initially framed as use cases in UML like notation and then used the pi4soa collaboration tool suite to create sequence diagrams (in which each link referred to an example message in the scenario being modeled) to support each of the use cases. These were then used to drive the development of a CDL model and that model was tested against the sequence diagrams. This represents the left part of the method shown below:

In the first case it tool less than one day to gather the requirements and deliver the tested model. In the second case it took 4 days to do the same. The technical contracts, the WSDL, the BPEL, the BPMN, the state diagrams, sequence diagrams and much more took a few clicks as they were generated from the CDL model.

It may sound fantastical and mythical that we compressed the effort by some 80%. But the fact is that we did. Not only that we found design flaws early both in our use of BPEL and WSDL. We found competing requirements and corrected them and we produced technical contracts that were far more rigourous and complete and unambiguous than we had managed to achieve by hand.

In the early development of the pi4soa toosuite we developed a full FpML model of derivatives trading from indication of interest through to the end of economic life of a derivative. I don't claim that this model was correct but the process of doing it took 4 weeks to complete and in the process a far greater understanding of derivatives processing was gained by both those doing the model and those providing the expertese of derivative processing. Similarly with TWIST and payments and more recently with HL7.

Some question the value of descriptions. All I can say is that the proof is fairly evident that describing something well has the effect that one better understands what is required and design flaws tend to be highlighted. In the insurance enagagements and the much larger FpML engagement the use of testable architecture, the gathering of requirements as sequence diagrams with messages, the modeling of the entire set of requirements and the formal testing of the model against those requirements and finally the generation of technical contracts is without peer. I know of nothing similar that can do this.

Fortunately I work, these days, for a large systems integrator (Cognizant Technology Solutions). This has given me the chance of trying this stuff out and showing I have always believed to be true which is simply that the impact of description through a formal method will help to change the way in which we can effectively do more for less with higher quality and so move the entire process of creating solutions up one level of abstraction with no loss in our ability to express a solution.

Offshoring and Specification - Improving the Global Delivery Model

steve@pi4tech.com (Steve Ross-Talbot) — Fri, 12 Dec 2008 16:42:00 +0000

Offshoring has been something with us for at least 10 years. Initially much of it was targeted at testing. There has been a lot written about offshoring and on the role specification plays in achieving a successful offshoring delivery model. So it is to this relationship between an engine that has a global delivery capability (and Cognizant is a fine example of this) and how to make it even better that I blog.

Offshoring is often done on fixed price terms. The financial size of the project and the way in which the contract and subsequent remuneration is managed relies heavily on specifications, governance of the delivery and change management. To date most offshoring companies have similar, although with subtle differences, models for doing this.

The advent of UML as a language for modeling and specifications has certainly helped in understanding what should be delivered. The use of programme management and enterprise architecture functions to govern delivery with clients is a common feature. Many offshoring companies and indeed those that were local Systems Integrators have to a large extent pioneered the roles that we play; from the programme management roles to the enterprise architect roles. Governance and supporting frameworks have been developed to help the process and have been used to great effect. TOGAF certified architects, MSP certified programme managers are in demand. Of course this does not mean TOGAF and MSP are the only games in town, I only mention them because they are well known.

The fundamental cost in offshoring the Software Development Life Cycle (SDLC) is one of people. And because people are involved the removal of ambiguity in specifications where possible is a critical success factor it both protecting the margins of offshoring companies as well as protecting the delivery of solutions to customers.

Not much has changes in terms of the specifications and the methods to create specifications nor in the way in which specification are used to guide the SDLC. Typically success is characterised by a model in which an Enterprise Architect may work alongside Business Analysts onshore to frame a solution and the Programme Manager liaises with the customer and Enterprise Architect to ensure a suitable roadmap for phased delivery of the solution. The same two roles work together on the contract details which reflect the roadmap. The programme (that is the collection of projects needed to deliver the solution) kicks off and the Enterprise Architect and Programme Manager (often with similar roles from the client) ensure the programme is well governed meeting all the targets and adhering to the standards of communication and delivery needed as well as managing changes.

Within the process that is enacted the specification of the solution becomes a key part for both governance and change management. The specification is the document (or documents) that detail what needs to be built in order to deliver the solution. Of course the entire process is larger than just this piece but for the most part the rest of the process deals with change management and seeks to ensure alignment of the solution to the customers needs throughout the life of the programme - hence change management because what we think is correct never is what is needed over the life of a programme; things change.

The specifications delivered to an offshore engine need to make clear what functions need to be written, what inputs they might have and what outputs they might deliver. The specification needs to make clear the order that functions can be used. I have not mentioned data explicitly because it has no meaning without the functions. A piece of data is just that until we decide to do something with it. What we do with it is essentially a function.

The challenge to creating and delivering good specifications is to ensure that they are internally consistent, that they are externally complementary - by which we mean that two pieces of software will work together or interoperate, that they are aligned to the business goals of the customer.

The way in which we meet the first challenge - internally consistent - is largely through governance and within it review. They way we meet the second challenge is the same. The way we meet the third challenge is through transparency with the customer of the SDLC and the solutioning process and of course through continued governance.

Of course when things change we need to assess the impact of that change to projects already in flight. Again this is done through review under governance.

The pattern here is that the key challenges are met with people based processes. And the problem with that is that it is ambiguous. The specification are often ambiguous internally and even more so externally. Not because people are not trying by because the level of abstraction for specifications is not amenable to adequately describe what is needed.

If we use UML State Machines and WSDL contracts as an example. We might have 100 services to create. They all have WSDL contracts. Some of the services will be stateless (typically data look ups, technical services and so on), some will be stateful (this doesn't mean they hold state within the interface but it may well mean that they have knowledge of one or more business transactions and so state relative to the business transaction becomes very important). If 20 of these services need to collaborate then the UML State Machines need to reflect that collaboration. The way we ensure it works is to check each State Machine against what we think are the related State Machines. As an example look at the two below, they should be complementary but are they?

Life got a little better when BPMN came along. It's level of abstraction is higher. But the problem with this is that it very quickly becomes unmangeable and unintelligable because the complexity is delivered as links across services (the roles or actors). Imagine a BPMN diagram for a seemingly straight forward problem. I show one below and you see immediately that the complexity makes it unreadable (and yes I know it is small but the point is that the picture is clearly complex).

So how do we do it better? How can we deliver better specifications and so improve the global delivery model and leverage offshoring at an industrial scale without needed so many heavy people based processes? In short how can we automate some of this and use computational power to make our lives easier?

The answer is to use testable architecture. In my next blog I shall show how it works and how it can be applied and the benefits that ensue. I shall leave you now with a simple business view of testable architecture for a simple example that was generated from a language that is unambiguous and really does specify at the right level of abstraction:

Some fun stuff

steve@pi4tech.com (Steve Ross-Talbot) — Fri, 21 Nov 2008 18:19:00 +0000

I lived and worked in the US from November 1985 to August 1987. During that time I probably learned more about IT than at any other time. I worked on some cool projects met some cool people and had a great time.

I spent many a Saturday night on the lower east side of Manhattan and small bar were I listen and generally lost myself to "Joey Miserable and Worms". See the link to the left.

Normally I blog on tech stuff but this time, for fun and in memory and affection of those times I leave you Joey Miserable and the worms and Worm Opus.

Enterprise Transformation

steve@pi4tech.com (Steve Ross-Talbot) — Tue, 18 Nov 2008 09:18:00 +0000

Overview
Transformation seems to be a bit of buzz word these days. I have seen an increase in bids that involve or are centred around transformation. There is much written about transformation that is available on the web and most of it is in the same vein, namely that IT is an enabler and that integration is costly and that SOA provides some way to reduce this cost and so increase the agility of the underlying IT assets. What I want to do is provide more detail on why this is so.

Enterprise Transformation and IT
So what is transformation in an enterprise and IT context.

Transformation at an enterprise level is about process, people and organisational structure. IT is only an enabler, its role is to automate where possible and assist where full automation is not possible.

For transformation to succeed it must have a business context. When we transform we know where we start from and where we need to go to. Transformation is better achieved and returns greater value if it ties return on investment along the way and becomes a programme of many projects that implement the transformation such that it is aligned to business imperatives. If there are no business imperatives that can be articulated then there is no reason to transform.

Enterprises engage on transformational programmes of change because they want to improve their own efficiency and because they wish to re-align their business with, what they see as, future market conditions. Of course the market changes and so the ability to continually adapt to change becomes ever more important to the place an enterprise needs to go. Equally an enterprise notion of efficiency also changes over time. Some processes that previously would be in-house become commodities and can be outsourced. But to achieve this the enterprise needs a framework in which the processes and the IT landscape sit that can support major adaptation.

The people in this transformation, as they have always been, are very flexible. Transformation can be painful but in the grand scheme of things people adapt and perform in line with the business imperatives that drive the transformation. The inhibitor to transformation is more often than not IT. Computer systems and software are not good at adapting to new situations and this is the bigger challenge to any transformation.

At an enterprise level, transformation change requires re-alignment of process, people, organisational structure and supporting IT to business imperatives. It isn’t just about IT, it isn’t just about people, it isn’t just about process or organisational structure. It is about business imperatives, business context and the way in which business goals can be achieved. Processes are simply a way of ensuring that all of the moving parts (people and IT) do what they need to do at the right time. People and organisational structure is about authority and roles to achieve business goals. IT is simply a way to automate and assist people through encoding of some or all of the processes to ensure greater efficiency. Given it is all about business goals and involves all of these moving parts it should come as little surprise that this is what Enterprise Architects do. They don’t do technology, they do transformation.

I've worked on process modelling since the late 1980's. First with Sema Groupe and then with Object Design for IBM on Fidelio (the code name for Flowmark which is now part of Websphere). It because apparent then that business processes would be very important to enterprises as IT became more prevalent in our society. The downside was always the integration of components and not the process topology. Designing a process as a model is the easy bit but enacting it over disparate resources is always the more costly exercise. Those of us that worked on process modelling back in those days knew that integration and reducing its footprint in the equation would always be the holy grail. If we could make the cost of integration low enough and the time taken to integrate short enough then IT would no longer be the impediment.

The role of the Enterprise Architect
Good enterprise architects have an understanding of the technology drivers that enable transformation to be effective and at the same time have an understanding of organisational structure and roles that need to be in place to enact transformation. They don’t have all of the answers but they think at a similar level to a CXO – which is why they often face off to them. They facilitate the reshaping of an organisation, an enterprise if you will, with the CXO driving and the enterprise architect providing grounded forward thinking advice and guidance on how transformation can be supported by IT in an holistic way commensurate with the business goals.

The role of Models, SOA, BPM and Business Rules
Having a good understanding of IT and IT trends in the future is one of the key skills that good enterprise architects bring to the table. The advent of SOA, the resurgence of BPM and the newer resurgence in Business Rules make transformational change much easier to achieve and much easier to drive. SOA cuts the cost of integration to more manageable levels through the use of standards and standards compliant tooling. BPM provides a framework for process encoding that provides the structural clarity of how an enterprise will work (across the IT and people divide). And Business Rules provide the controls for steering the enterprise ship as it sails towards it’s archipelago of business goals.

But of course none of this is any good unless we can capture where we are and where we need to go to. Having a profound understanding of an AS-IS landscape – by which I mean the process, people, organisation structure and IT – is a base for transformation. Such an understanding needs to minimise ambiguity and maximise clarity. Good models become essential. Good models that can be tested become highly valuable and good models that can be reasoned over become a differentiator.

Having that AS-IS state allows the CXO team to better understand where they are and so construct similar models that describe where they want to go.

The journey to a TO-BE landscape cannot always be determined in advance, it is a journey. To be able to flex and adapt the enterprise without being hide-bound by IT enables the CXO to try things out rapidly. In much the same way as we use agile methods to develop solutions in the face of inexact requirements and in much the same way we might use CMMI to drive iterative improvements we can apply the same techniques to the enterprise as a whole and so continually adapt it to improve efficiency and meet business goals.

Where to start
The first step of this journey is to move towards service enabling the enterprise. Capturing the key processes, automating where we can picking low hanging fruit to turn an AS-IS landscape into a more agile AS-IS landscape. Picking the low hanging fruit can often help to pay for the enablement over time. When enough enablement has been done the transformational journey can begin in earnest because at that point enough of the enterprise is flexible and agile enough to be flexed.

A danger in picking low hanging fruit is to silo enterprise transformation thinking. Looking at one process is never sufficient as it does not engender any synergy. So a single process view does little to help transformation. Rather a more global approach is needed. Capturing the AS-IS and then transforming to a TO-BE state over time requires a global model approach which is neutral to the technology and crosses process boundaries. Testable architecture concepts help to capture a global model by documenting an AS-IS (and enabling a journey to a TO-BE state) to be written formally as a collaboration in which processes may collaborate at the top, middle or bottom of the process graphs. This helps to rationalise the IT real-estate and encourages synergy.

Conclusions
Consider the humble Ford car manufacturing plant and the American football team. In the case of the former they can re-purpose a plant to manufacture on car type or another in 24 hours. They have delivered adaptability for their business. In the case of the later they coach has a play book and a set of behaviours (the players). The goal is to win the game and the objective is to make a first down each time or stop the other team or take a field goal. The coach matches behaviours to plays at each stage of the game demonstrating adaptability.

Thus for me the key to enterprise transformation is to free the enterprise from the moribund pace of change of IT through service enablement, focussing on early ROI to justify the enablement and with a longer term vision of CXO’s to have a flexible and adaptable enterprise for the future. This is why global models are important (and so testable architecture given first through CDL tools). This is why SOA is important. This is why BPM is important and this is why Business Rules are important. They all help in enabling adaptability at differing levels of a enterprise, from the top, in the middle and at the bottom.

And finally, the guardians of technology enablement are not the vendors – they have little insight as to how transformations are performed – it rests with the systems integrators leading the industrialisation of IT.

References:

IT for Enterprise Agility

SOA and Large Scale and Complex Enterprise Transformation

BPM is Not the Same as BPR

Building the Agile Enterprise

Finding the right services to a problem

steve@pi4tech.com (Steve Ross-Talbot) — Fri, 12 Sep 2008 11:38:00 +0000

Almost certainly the will be the start of a stream of blog entires. I am still mulling over the plethora of techniques we are told about and still trying to see if any of them really help or if it is a case of good design principles rehashed yet again. Perhaps if I come up with something concrete we will call it YASIM (Yet Another Service IdentificationMethodology). Anyway here goes part 1.

One of the most difficult things to do in SOA-based projects is finding the right services. There is much fear uncertainly and doubt about this. To meet the challenge many vendors and integrators are seeking to create methodologies to support the process. Consequently there are lots of methodologies about logical designs and how to derive services from them. Some use data flow techniques other use process modeling techniques and all have some taxonomy of services that classify services (albeit with different names) as "business", "data", "technical" and "utility".

The data flow and modeling techniques are intended to tease out services that are business aligned by looking at the data (data flow) or the process. Services are derived from such views and then classified.

Data modeling apart - largely because it is not the way in which the prevailing winds blow - relies on some notion of activity grounded to a role. BPMN is a typical graphical language that is used. This technique is fine for the most part although in the case of BPMN scalability is an issue because it put roles at the front and obscures the process as a result, but nonetheless it works for the most part in deriving services.

Of course deriving what services are needed is only one step in the process of delivery. What is needed in support of this is to identify services that might fulfill need. In a greenfield site this is not a problem but as SOA adoption grows one of the benefits is supposed to be reuse. So how do we ensure reuse and what does it mean?

Finding a service that has both the correct method signatures and the correct behavior, the keystone of reuse, is for the most part an aspiration. It would be wonderful if we could ask a service repository for a service with methods "foo(FooXML)" and "bar(BarXML)" in which "foo" is always called before "bar" or in which order is irrelevant and for the repository to tell us what matches our query.

The reason why we cannot do this sort of search is in part because the behavior of a service is not captured in the repository and because the architecture description (data flow model or process model) does not support any formal linkage between it and the service descriptions in the repository. So we are left to figure it out and the best we can do is find that a service has a "foo" that takes a "FooXML" and a "bar" that takes a "BarXML" as input (similarly for the outputs).

I was at a recent Scribble meeting at Imperial College and I saw the future is now. The Pi4 Technologies Foundation along with Imperial College and Queen Mary College and a few others have been working on a language called Scribble. It is "son of" WS-CDL. A much cleaner curly brace notation for describing teh dynamic behavior of an architecture. Most importantly it has a behavioral type system. The demonstration showed that an encoding of WS-CDL can be rendered into Scribble and then the type system can be used to check for behavioral conformance of JBossESB actions. If you change the WS-CDL having generated the JBossESB (directly or by hand) you can see areas of conformance and non-conformance. Finally we have the linkage between the intent of the architect and the implementation contract of a service in a true SOA platform.

I am looking forward to playing with this when released as part of project Overlord and I expect it make reuse the norm rather than the exception and to do so at a fraction of the cost.

Mulling over architecture

steve@pi4tech.com (Steve Ross-Talbot) — Mon, 21 Jul 2008 11:35:00 +0000

I've been mulling in no specific direction today. Letting the wind take me to wherever it wishes and that often leads me to think more clearly.

I was talking to my dad over the weekend. He was involved in avionics most of his working life and was the examiner of the institute of Quality Assurance in the UK. We were talking about the Farnborough Airshow - which I attended on Friday - and about fly by wire. The European Fighter Aircraft (Typhoon) is a fly by wire as is the A 380. I don't know about anyone else but the standard of software development would make me concerned if I had to fly in one of those. I try to forget it all when I board an aircraft so I don't worry.

It turns out that much of what they do to increase the reliability of fly-by-wire is to use redundancy. Triple systems is one approach that is used. The components are developed independently and then monitored. When they diverge majority voting is used to determine the likely correct behavior. It is statistical because there is no guarantee that the behavior of the two that agree is correct. It is simply the case that two agreeing is likely to lead to correctness.

In high availability system of this nature they use multiple compliers too and they might choose to use different chip sets.

Given my stance on top-down it is heartening to see that project definition is what often guides these systems. No code is cut until after project definition which in turn provides the specification of the system. So what happens when they change things? They negotiate the change and provide a plan for the introduction of the change. It cannot be done on the fly because the complexity of the change often mitigates against a more agile approach. So they simulate they test and so on. What they have is very good governance processes which document the change, the impact and the resulting tests prior to productionisation. All similar to the approaches we use in commerce oriented solutions without simulation and without testing the architecture in any way.

The role of project definition is to provide the requirements against which testing can be measured and against which simulation can occur. The simulation provides a first step towards testable architecture ensuring that the overal design is commensurate with the requirements.

As an aside High Integrity Software development became a real vogue in the 1980's. One of the earliest proponents of formal methods which have underpinned High Integrity Software has been Tony Hoare (Elliot Brothers 1960 until 1968) who oddly enough was at Elliot Brothers during my dad's tenure (John Talbot 1961 until 1965 and then again 1968 until retirement in the 1990's).

So what does this mean to the world of software and commerce. Formal methods are valuable but not a panacea. They need to be introduced by stealth with their benefits laid out. They need to be employed early. As Anthony Hall elaborates:

"It is well known that the early activities in the lifecycle are the most important. According to the 1995 Standish Chaos report , half of all project failures were because of requirements problems. It follows that the most effective use of formal methods is at these early stages: requirements analysis, specification, high-level design. For example it is effective to write a specification formally rather than to write an informal specification then translate it .It is effective to analyse the formal specification as early as possible to detect inconsistency and incompleteness. Similarly, defining an architecture formally means that you can check early on that it satisfies key [functional and non-functional] requirements such as [message order and content], security [and performance SLA's]."

Formal method have been used in avionics for some time. Hence Tony Hoare's involvement in Elliot Brothers. They are for he most part hidden and become a function of tools that are used for design. The use of the Z notation in the early 1980's found popular acclaim in Ada based systems. The problem was it's cryptic nature and therefore lack of skills in using it. Which is why stealth is a good thing. Tie it up in a tool and make it easy (just like type systems in programming languages).

We have a much clearer formal understanding today of distributed computing through the work of Tony Hoare and Robin Milner. What is needed are tools to help us define architectures that remove the ambiguity of human translation and provide a mechanism for the analysis that is needed, henace the cry for formalism. The pi4soa tool suite is but a start. It can become more refined and integrated with other tools (such as Archimate and those specific tools that support Archimate). Architecture tooling and tooling for design is not the most popular of directions because of the lack of runtime scale for remuneration. But they are much needed as in the end they will enable solutions to be build faster, with higher quality and at lower cost whilst remaining suitable agile and aligned to the business and this is what formalism (suitably hidden) can provide.

The Industrialisation of IT

steve@pi4tech.com (Steve Ross-Talbot) — Tue, 01 Jul 2008 08:25:00 +0000

Possible the most important invention that gave rise to the industrial revolution was the micrometer. The inventor of the micrometer was William Gascoigne in the 17th century. It was directly responsible for the engineering discipline in constructing the steam engine and in constructing the Enfield rifle that was used during the civil war in the United States.

What the micrometer did was remove ambiguity. It gave rise to a language of design that enabled precision engineering which by extension gave rise to industrialisation with bullets being made in one place and gun barrels in another.

What has this got to do with CDL?

CDL is possibly as important in the industrialisation of IT. It gives us a language of precision of a system of services which in turn ensures that services are precise (by design) and so interoperate properly - just as the micrometer did for Enfield and Stevensons Rocket.

In classic engineering today simulation is used along with some formal mathematics to test out a design to ensure that it will work. In CDL the same principle is used to simulate and to test so that before a line of code is cut the CDL description is shown to be valid against the requirements and to be correct in computational terms (i.e. free from live locks, dead locks and race conditions).

Testable architecture along with a language of discourse that is precise removes the ambiguity between implementation and requirements. It enables industrialisation and facilitates off shoring of implementation in the same way that Enfield used the micrometer and the precision it gave to design to manufacture solutions in different locations and yet ensure that things work when they are put together.

Response to Luis's comments in my last blog entry

steve@pi4tech.com (Steve Ross-Talbot) — Mon, 23 Jun 2008 21:32:00 +0000

Firstly thank you for the comment Luis.

It has been a little while since I last blogged. In that time the latest Pi4SOA release came out. Some of it's capabilities are listed below in the narrative.

To get the latest release follow the instructions at the end.

On to my response to Luis's comments.

Luis wrote:

Very good article indeed. It clearly describes the main doubts most people have regarding the real added value of CDL and how to addressed it. It is clear vendors are more worried about short term ROI other than best practices and real heterogeneous enterprise architecture; evidence of this is how vendors sell “SOA Suites” as a product / package and not as an architecture approach or practice as it should be (this is probably one of the reasons why many SOA projects end up in DOA –dead on arrival– instead of addressing the real business needs and technological value)

One suggestion; it would be nice to mention how and when CDL can be plug together with other technologies such as BPMN, SCA and BPEL on the different stages of a SOA project and the roll it has one the solution is in place (e.g. in the governance).

Here is my response:

The Pi4SOA tools suite currently supports BPMN. It is simply and export format in which CDL is exported to BPMN. However CDL is richer that BPMN so it is not free from loss of the expressions in CDL. However it may serve the role of review collateral.

BPEL is also supported. You can generate BPEL just as you can generate Java. The downside is that BPEL is more restrictive than CDL because CDL is wider than classic web services and provides message exchange patterns that BPEL cannot handle but which are applicable to SOA (i.e. first class notifications). The BPEL generation is still prototypical as it does not garner much demand. However I think that Overlord will change that.

As to SCA, no current bindings exist to SCA but I do not think that SCA in and of itself is really a target for CDL as it fits two level below rather than one level below. One might of course make the association of SCA to ESB in which case the latest release supports JBossESB out of the box. The problem with ESB's is that there is not real standard. Rather an ESB is a collection of integrated components (Message Bus, Orchestration, Registry, Business Rules and adapters).

Governance is all about control and traceability. This is exactly what CDL provides as an SOA blueprint for a dynamic model. It is the language of architecture in which Java, C# and BPEL provide business logic inside services and in which CDL describes the collaborative behavior of the services as peers. It provides traceability back to requirements (example messages and sequence diagrams) today and in the future will also deal with the non-functionals (SLA's WS-Policy statements and so on) and it provides total coherence to implementation through Java generation, UML (XMI model) generation, and BPEL generation as well as providing runtime checking of behavior against the description. So it provides top to bottom alignment from requirements to implementation. In this way it provides a governance platform that can help to manage the complexity of change over a large real-estate of services. Which is why Cognizant and Redhat are interested in CDL.

Downstream we might try to join it up with ArchiMate, which will provide the route to requirements from the business. But that is some time away and work has yet to start. If anyone is interested then contact me at at the Foundation (see below).

To use the latest release follow the steps below:

1. Go to www.pi4soa.org
2. Select "Download->Browse All Files
3. Press the green "Download" button
4. Select the appropriate platform and download (See below)

pi4soa2.0.0.CR1-eclipse3.3.2-linux.tar.gz
pi4soa2.0.0.CR1-eclipse3.3.2-macosx.zip
pi4soa2.0.0.CR1-eclipse3.3.2-win32.zip
pi4soa2.0.0.CR1-Release-Note.pdf
pi4soa2.0.0.CR1-withsrc.zip
pi4soa2.0.0.CR1.zip
pi4soa.sar

I also have lots of example which I am happy to share. To get them you will need to email me at pi4tech (steve@pi4tech.com)

Show me the money in CDL

steve@pi4tech.com (Steve Ross-Talbot) — Wed, 07 May 2008 18:01:00 +0000

Summary

The value of CDL is that it takes us from art to engineering by ensuring good governance that is supported by tools throughout. It gets you to a solution much faster and more accurately with higher quality. It does this through formal validation of CDL descriptions against requirements, through monitoring of services against CDL descriptions and directed guidance of services construction through generation based on a CDL description. The formal tie in of a description to requirements and the linkage directly to monitoring and generation is what provides quality and time to market coupled with the level at which CDL as a description languages operates.

WS-CDL (CDL) has been around now for some time. The Pi4SOA tool suite has found great favour among vertical standards (ISDA, ISO, TWIST, HL7 and many others). Researchers continue to plough a furrow towards ever more interesting analysis of CDL as well as looking towards son-of-CDL. With Redhat's announcement of their SOA governance project (Overlord) and the central role played by CDL and the Pi4SOA tool suite one could be forgiven for assuming that SOA platforms vendors and tool vendors show interest in CDL and are actively looking at working on it and providing it to their communities.

So why is this not the case?

Some of it is still rooted in the adverse and misleading publicity that CDL received at the hands of some analysts and many large vendors. The deliberate confusion created in the minds of the population at large through the BPEL vs CDL debate caused much damage and was founded on many many fallacies and misunderstandings. But perhaps the fundamental reason for the lack of tools from vendors is rooted in the classic question "show me the money".

Despite some large corporates asking for CDL tooling, vendors have not really provided anything at all. And so we are left with a few tools largely open source from smaller players.

The SOA platform vendors make their money on run times not on design so they are focussed on execution and not description. This is why VC's often say you cannot make money from tools. It is why Eclipse is open source. So Java, BPEL J2EE Application Servers, ESB's and all of that stuff is all about execution and the scale that run time brings to revenue for vendors.

CDL is a description language not an executable language. At first glance it is not clear where there is any revenue. It has no runtime component. It's value at first glance is in clean concise accurate descriptions of System Architectures in terms of their observable behavior and message exchanges. So it is all about design and not execution.

One might argue that WSDL is also a description and yet has value. But that value is entirely driven by its use in execution. To have Web Services a WSDL description is needed. The attendant software to type check, marshal and un-marshall operations and data and to ensure correct message exchange patterns are adhered to is all part of the run time machinery needed to use WSDL.

WSDL has another value in that it is a language to describe the technical contract of a single service. It might not capture behaviour but it does capture the functional footprint and data types that a service needs to be useful at all. But this value, as a contract, is not why SOA Platform vendors invest in WSDL. The reason they invest is because they can clearly see the value in their run time environments and so the revenue that accrues.

So what of CDL? As with WSDL, CDL is a very good language for describing all of the contracts needed for a set of services. It describes the collaborative contract that is, in effect, a System Architecture description. But that, as far as SOA Platform vendors would be concerned, does not generate sufficient revenue to justify investment.

On the other hand there are many UML vendors who provide design time tools that users do buy. So there is a value. IBM have Rational, Magic have Magic Draw and so on. But it is not a big revenue ticket business. It is niche.

CDL can play a role in the execution phase and this is where the key revenue value can be clearly seen. If we have a System Architecture description that described the externally observable behavior of services then we can monitor the run time services against that description. This technique is like BAM but is really BAM with teeth as we can measure what we observe against what we expect. The result is monitoring, or governing, services such that we can determine where problems exist based on an artefact that also governs the change of the system as whole and may be used to drive evolution. This is why CDL is a key part of Redhat's SOA Governance project called Overlord.

From a user perspective, that is some entity wishing to deliver a solution, the value is more profound. On one side CDL provides possibly the very first formalised way of delivering an artefact, the System Architecture description, that can be validated against requirements and so yields testable architecture. This artefact represents to TO-BE state of a system. On the other side a CDL description can be used to describe, in much the same way, the AS-IS state of the system. In this case the artefact can be validated by automated observation (monitoring) to ensure that it truly represent the AS-IS state. When there is no variance in the monitoring we have a stable AS-IS description.

So CDL provides a means of having testable System Architectures for a TO-BE description and provides a means of defining an AS-IS description and means of validating that description against an existing IT real estate.

Clearly the difference between the AS-IS and TO-BE state represents the scope of work to be carried out. Because CDL is a formal description, analysis to identify the gap, between AS-IS and TO-BE, is much easier, faster and can be supported by tools to ensure that the gap is correctly identified. Furthermore the changes to the AS-IS state can be managed over the lifetime of a programme of work with continuous real time governance, through monitoring, to ensure that the solution delivered is correct at all times.

The value of CDL, in a nutshell, as has been blogged before, is that it takes us from art to engineering by ensuring good governance, that is supported by tools throughout. It gets you to a solution much faster and more accurately with higher quality.

As Redhat start to use the monitoring aspects of CDL SOA vendors will inevitably move towards it and I would anticipate SOA Governance and BAM to settle on CDL.

The end of coding as we know it?

steve@pi4tech.com (Steve Ross-Talbot) — Sun, 16 Mar 2008 18:15:00 +0000

I was talking to a friend and colleague, who shall remain nameless, about the use of models as a principle means of deriving applications. Oddly enough, the day before, I was also talking to one of my new colleagues at Cognizant about something not dissimilar. In the former case there is at least one (and probably many) organisation who now seek to reduce the coding burden and have made efforts to turn their coding shops into testing shops with a little coding on the side. In the case of the latter we were talking about the real IP being in the process models and not the coding.

Clearly there is much work in MDA circles to solve these problems. After all there have been attempts at moving to executable UML Few if any have really succeeded. And those that come close tend to do so based on a more siloed view of an application. There are also initiatives within OMG to codify process models based on BPDM and relate them back to UML. This latter move is of considerable interest because on the one hand it recognises that UML today does not facilitate the encoding of business processes and it recognises the need for some description of the peered observable behavior of a set of roles which we might call a choreography description.

Can we really move towards a world in which models drive everything else and do so automatically? And if we can what do these models need to provide. What are the requirements?

I would contend that any such model, we might call it a dynamic blueprint for a SOA, needs to fulfill at least the following requirements:

A dynamic model MUST be able to describe the common collaborative behaviors of a set of peered roles.
A dynamic model MUST NOT dictate any one physical implementation.
A dynamic model MUST but be verifiable against requirements.
An implementation of a dynamic model MUST be verifiable against that dynamic model.
A dynamic model MUST be verifiable against liveness properties (freedom from dead locks, live locks and race conditions).
A dynamic model MAY be shown to be free from live locks deadlocks and race conditions.
A dynamic model MUST be able to be simulated based on a set of input criteria.
A dynamic model MUST enable generation of role based state behaviours to a range of targets including but not limited to UML activity diagrams, UML state charts, Abstract WS-BPEL, WS-BPEL, WSDL, Java and C#.

Let me examine what these really mean and then I shall summarise what I think the implications are on the software markets as a whole.

Requirement 1 really states that any model must be able to describe the way in which services (which might be the embodiment of a role) exchange information and the ordering rules by which they do so. The type of information exchanged might be given as a static model (requirement 2). The ordering rules would be the conditional paths, loops, parallel paths that constitute the collaborative behavior of the model with respect to the peered roles.

Requirement 2 simply states that a static information or data model is required and that this can either be in place when creating a dynamic model or it may be created along side the dynamic model which would provide context for the information types. When we iterate between sequence diagrams and static data models today this is essentially what we do anyway. The difference is that the dynamic model is also complete unlike the sequence diagrams which provide context on the basis of the scenario that they represent.

Requirement 3 says that any dynamic model should not dictate any specific physical implementation, that is it should not require a solution to be hub and spoke, peered, hierarchical and so on. It should be capable of being implemented in a range of physical architectures which are independent of the dynamic model.

Requirements 4 to 6 say that a model must be subject to and support various forms of automatic verification just like programming languages are today when we compile them and the compiler picks up errors and so prevents the code from being made executable. In the case of a dynamic model we would want to ensure that the dynamic model meets a set of requirements for the domain that it represents. This might be achieved by validating a dynamic model against an agreed set of messages and an agreed set of sequence diagrams which collectively describe one or more use cases. On the other hand we would want to use a validated dynamic model, which as a result of validation we know meets our requirements, to verify that an implementation of that model conforms to the model. That is that there does not exist any observed execution of the implementation across all of it's constituent services any set of observable exchanges or conditions that cannot be directly mapped to the dynamic model. Putting it another way we want to use the dynamic model as input to some form of runtime governance applied to the behavior of our set of peered services. The requirements that mention liveness, live locks and so on are really not any different to saying that in any programming language it is illegal to access an array of 10 elements by writing x = array[11]. The difference is that we are looking to prevent badly formed and potentially disastrous problems arising in a distributed system and not in a single application as do compilers.. Model checking applied to a dynamic model for distributed systems is one way of ensuring that this does not happen in much the same way that type checking prevents errors at a localised application level. I mentioned something akin to this in my blog on the workshop I attended which was entitled "OO Languages with session types ".

Requirements 7 states that a model must be able to be simulated. What this means in practice is that if a dynamic model captures the collaborative behavior of a set of peered roles then we must be able to provide such a model with some input data and see the dynamic model activated. For example if a dynamic model starts with the offering of a product then we must be able to direct it to some product information and see the exchanges that then occur. Equally if we introduce a number of bidders in an auction system we need to be able to enact the choreography.

Requirement 8 is all about reviewability - if such a word exists. Simply stated it is the ability to generate or display a dynamic model in a way that reviewers can understand, comment and so sign off on.

If we had a language that we could use to describe such dynamic models, and of course I would contend that WS-CDL is a good starting point along with BPDM, and if you are interested in the future then look at Scribble too, then what does this means for for the software market as whole? In simple terms it changes the shape and size of delivery and has an impact on testing. It compresses things.

On the one hand we can view the dynamic model as UML artefacts empowering implementors. If we know that the dynamic model is correct with respect to the requirements, and we know that the dynamic model is correct with respect to any unintended consequences (aka liveness) then we can be sure that the implementors will have a precise and correct specification in UML of what they should write on a per service/role basis and so ensure that all the implemented services will not have any integration problems. It makes it much more efficient to outsource development because the dynamic modeling can be done close to the domain and the development can be done where it is most cost effective to do so - hooray for off shore development. Coupled with the ability to use the dynamic model as input for testing it also becomes possible to verify that a service is playing the correct role as it is being executed in testing.

On the other hand, if we can generate Java do we really need coders? And this is the dilemma. Can we really do without coders. If the high level dynamic model only deals with the externally observable behavior then somehow we still need the internal behavior (the business logic). If the internal behavior can be described fully in UML and code subsequently generated we can indeed generate everything. The dynamic model of the system as a whole plus the UML models for service business logic combine to provide a two step high level description of a system in which no code needs to be specified at all. So no coders? Of course it sounds too good to be true. Where does the code go? Where are the actions specified? In UML this could be done using an appropriate action language, something that has found it's way into UML2.0 but as yet not fully formed as a concrete language. Someone still has to write this stuff, so the coders just move up the stack and become more productive as they did with the onset of OO languages as a whole.

Is this the end of coding as we know it? One thing is for sure it is not the end right now. How far and how fast the growing wave towards modeling as opposed to coding will take us, for me at least I cannot see it is all the way. The action semantics still need to be coded or written textually and that is really coding by another name. I remember in the early 1990's much was made of visual programming languages. None of them made it.

What it is all about is structure and making the structure of things visible and so easier to manipulate and that is a huge leap forward because we simply have never had anything that enforces structure for a distributed system before.

In the grand scheme of things the very fact that we can articulate such possibilities (the end of coding as we know it) means that our industry as a whole is maturing and our understanding of the complexity inherent in distributed systems (SOA and the rest) is becoming clearer every day. It does not mean that we are there yet but because we can now think about the requirements of a language needed to describe such structure we are at least on the right path.

General news

steve@pi4tech.com (Steve Ross-Talbot) — Mon, 25 Feb 2008 15:11:00 +0000

Not often I blog on something quite so general and to keep your interest I do intend to do a major piece on SOA for business and management rather than just a the usual techie dimension. It just takes a while to get my thoughts in order to do it.

On a more general topic I have changed jobs. Having been an entrepreneur for the last 10 years I have decided that I wish to devote time and energy to doing what I can in a larger organisation but one that is fast enough moving that I can use my entrepreneurial skills in. To this end I am now working for Cognizant as the lead architect for their Advanced Solutions Practice in Europe. All very exciting stuff because these guys are really growing fast and that gives me a whole lot of problems based on methodology and technology support for it to focus on.

I'm still very much Pi4 Tech and still associated with Hattrick (non-exec on the board).

I'm looking forward to bringing the experiences from my new role at Cognizant into the blogsphere.

Workshop on Web services, business processes and infrastructure

steve@pi4tech.com (Steve Ross-Talbot) — Wed, 13 Feb 2008 10:13:00 +0000

I attended a really good workshop last week and thought that I should probably blog a bit about what it was all about. There were some really good presentations. To the authors of these, alas sorry I missed a couple so I cannot blog about those I missed. But here goes ....

There was lot on global models during the course of the two days and a lot on session types (these are the types that WS-CDL was based upon and provides a behavioral type checking facility to determine liveness properties - i.e. does it deadlock or livelock and so on).

Several papers stood out for me.

There was one from Andy Gordon on F# - a formally grounded language for encoding data centre run books, similar in intent to that used at one of my old companies Enigmatec Corporation Ltd. What Andy has done is formalise a language for managing data centre, which when you step back and think about managing such assets really does have to be precise so formalisation is really important.

There was one from Joshua Guttman on global models (using WS-CDL) and security. Great paper because it added contextual security based on process. Something I have longed to see but have never had the ammunition to consider.

There was one from Mark Little about distribution and scalability which was very enlightening and showed many of the issues that concern today's web based applications and what we need to focus on to describe and manage transactions in an unreliable context (see link to mark on my links).

There was one on Sock and Jolie from Claudio Guidi's and colleague. Sock being the formal model and Jolie and implementation that enables complex systems of services to be enacted using a curly brace language (Jolie). They gave a great demo too.

There were a couple on session-based languages that really stood out. The first was from on her work on OO Languages with session types and the second was from Ray Hu on Distributed Java. The latter, which I have seen before, added a few jars which abstract communication away. Coupled with what is akin to an interface in Java but is actually a session type documenting behavior between processes it provided really good session typing and checking to ensure things work correctly between processes. For me this fits the bill as regards language extensions to Java that make Java a good end-point language with a strng notion of contract.

One paper dealt with a topic very close to my heart which is how can we use a global model (aka WS-CDL) to find services that meet the necessary behavioral footprint expressed as roles in WS-CDL If we could do this then when we write down out SOA blueprint for both existing systems and extensions we wish to make we can ensure a higher degree of reuse, not just at a functional matching level but at a behavioral level. The work is by Mario Bravetti and I hope very much that we can get Mario involved in the Foundation to help us move this to a reality for many people.

On some more comerically oriented presentations there was one from Matthew Rawlings and one from Dave Frankel. These two dealt with the realities of modeling and documenting standards that are very complex. Matthew is well known as an Architect and deep thinker in financial services and Dave is well known as one of the key people behind UML

The final paper I wanted to mention was given by my long time colleague, Gary Brown. The Foundation which was started by Gary and I has moved on. WS-CDL is where it is but we embarked (well less me and much more Gary and Kohei Honda) on looking at how better to describe global models. And so Scribble was born. Gary presented Scribble and in particular showed a simple HelloWorld process and how it is represented in WS-CDL and in Scribble. Scribble was great! It is early days for Scribble and I am aware that Scribble will try to be compatible with WS-CDL (so don't wait) but it is so clearly the was to go and I look forward to using it when it has all been done.

Thanks to the organisers (Marco Carbone, Nobuko Yoshida and Kohei Honda). It was very stimulating indeed.