SOA Manifesto rambiling part 2 (the value statements)

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

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

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

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

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

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

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.