Microsoft commits to Web Service Openness

There has been quite a bit of noise going across the wires after Microsoft announced they they are allowing anyone to use their patents with respect to several key WS-* standards. Its their Open Specification Promise. It only covers those patents described in detail (rather than referenced) which is a bit of a shame, but its a big step in the right direction to removing ridiculous patent blockers to technology adoption.

It includes WSDL, so I'm assuming that applies to any WSDL specification, and a whole heap of the latest and greatest standards that people will begin to want to use.

Nice one Microsoft, just one small question...

What about BPEL? Is it that there are no Microsoft patents in this area, or that these aren't being opened up yet?

Technorati Tags: SOA, Service Architecture

SOA Governance - an IT organisation

One of the big questions of SOA is what it does to the normal IT organisations. I've blogged a couple of times about how SOA helps create a series of smaller projects inside a larger programme which gives you smaller teams and helps (even without using Agile methods) create more Agile projects.

This move towards service development pretty much demands that you move towards a service oriented organisation. To ensure that services are developed effectively and maintained effectively you don't want to keep having lots of different people having to learn how the service works and as SOA is about becoming more business oriented you need to maintain that knowledge at all levels, this means dedicating people to specific areas and services.

This means changing the IT organisation and its structure to match the business service architecture, including treating IT as a business domain. Taking the Level 0, Level 1, Level 2 approach from the SOA methodology this drives through into the organisation structure.

There are three distinct areas in the org chart

1. Business - The business owners of the various services, potentially delegating authority on lower level services to people inside IT while retaining a sign-off role
2. Service Delivery - The part of IT that delivers the business services
3. Platform Delivery - The part of IT that delivers the underlying platforms and the technical services that are required to deliver the business services.

Each of these has different KPIs, and the Service Delivery teams have two sets of measures.

Business - Must commit to a long term view of IT if they want an IT organisation that evolves in the way they want and reduces the overall cost of IT and gives them the dynamic change they want. This means agreeing to committed plans that enable multi-year planning, not multi-week. It also means that the business must be aware that if they do want to do something tactical that it will require an "offset" investment.

Platform Delivery -Responsible for defining the IT standards and delivering the mechanism for measuring and enforcing them. This means providing the base platforms and functionality. It is this team that is responsible for defining what technical tools should be used and how they should be implemented.

Service Delivery - Measured by the business against delivery and by platform against quality.

Business Services

Each service has two "heads", one from the business, one from IT. The business person is responsible for defining what the service is the IT person is responsible for how it is delivered. Questions like "XML Schema" et al are the responsibility of IT.

Within a Service (e.g. Level 1 Services inside Level 0) the IT leader is responsible to the leader of the level above.
And for each area you have a similar structure (depending on the service structure)
The most senior architect within a given area is responsible to the platform team for the quality of their delivery. This architect is responsible for working with the platform team to determine the best technology approach. The business service architect knows the drivers and change required, and the platform architect aims to deliver a consistent infrastructure so together they've got to select the right solution to deliver both the service, and the overall estate.
The Platform team provides the technical expertise to make sure that the business services are delivered correctly. It might even include some common technical elements that are required across all the different service areas, and critically someone to make sure that the data being collected is of a decent quality and at least vaguely consistent! The platform team isn't service based in the way that others are, its capability based, so in here you get the testing teams, deployment teams and all of those bits that everyone requires.

Then once we have this all in place and we've targeted people as owners (and please do note that one architect or business person can support multiple services within a domain if they are all relatively small) we actually need to get onto development.

The recommendation here isn't to have every service with a dedicated delivery team, you just want a couple of core people to be permanently assigned, the architect, analyst and probably the technical lead. It is a good idea to have developers at least generally assigned to one service area (Level 0 or Level 1) of course.

When you have a programme kicking off the first job is obviously to determine the services that are impacted by the programme. This means that project/programme managers live elsewhere in the organisation and are assigned to programmes as they are kicked off. Once this is done the programme manager and the lead service architects from the impacted services (and hint of the day restricting programmes to one top level service makes things easier) and decides on the right approach and delivery method(s). Then you assign the resources to the programme which will then be directed into the various service teams.

The programme team is responsible for the overall requirements and delivery, and making sure that the various service changes are integrated together and the quality of the final programme delivery. The development effort is led by the service lead (or architect) with resources assigned by the programme manager.

If platform changes are required then its pretty much the same except that it includes assignment of resources into the platform team. Once the programme is finished its transitioned into standard running and the development teams are wound down.

During the delivery the service leads are responsible to their senior architect and the platform architect for the quality of the delivery. The testing team that is assigned comes from the platform team and is responsible for ensuring that the delivery meets the platform standards. This dual responsibility is aimed at reducing the "rush to live" quality cutting that reduces the long term flexibility of the solution. Sure sometimes the programme has to go live, but again this means that it needs some offset funds, the things the business committed to up front.

The key here is that everyone is bought into the service architecture, the governance is there to enforce what needs to be done and it does that by taking that service architecture as its base. This makes sure that SOA isn't just a series of powerpoints, its baked into how IT operates and delivers.

Technorati Tags: SOA, Governance, Service Architecture

SOA - Federation and the pursuit of liberty

Way back when Microsoft annouced Passport as the way for applications to share identies, namely by having a "trusted" party in the middle (Microsoft) who would validate all the identities. Now this didn't go well for several reasons, the fact that the Banks didn't like the concept of a single organistion basically being able to tax every transaction was certainly one, the lack of general trust in Microsoft's privacy rules was certainly another. The alternative, much prefered by the banks and by people who don't like the idea of one company holding everything is to have a federated security model, and thus was born the Liberty Alliance.

Now federated identity is much to be desired in SOA as it provides a great way to be more loosely coupled around one of the critical NFRs on the systems, but it is pretty hard. Looking over at the Macehiter Ward-Dutton (the analysts who blog) I came across an article on the latest round of companies to pass Liberty certification. This is great news as we move towards more collaborative business applications this sort of security problem is going to become much more common. Imagine doing multi-supplier collaborative applications without a decent federated security, you'd end up in the old B2B application scenario that requires a big blob in the centre.

Liberty will hopefully enable applications to better collaborate between organisations, this is certainly going to be critical as systems become more external and more dynamic.

Technorati Tags: SOA, security, Liberty Alliance, Service Architecture

Efficiency in the IT Supply Chain

I was speaking with Bola Rotibi at the non-blogging analysts Ovum (get with the programme guys) today about trends and skills in the future and we got talking about what roles won't exist or will be squeezed as these new SOA approaches and technologies begin to take hold.

So we got chatting about thinking about IT delivery like a supply chain, and thinking about what the most inefficent parts of the current IT supply chain are. Now unlike a decent SOA approach the current supply chain is very very process oriented. Now the most common supply chain these days (and sure Agile people can have a shout about being better but lets just wait a minute eh?)

(Apologies for the huge gaps on the image but I've had to use PPT and its "Save As" is slide only not just selected (ala Open Office))

Now the key bit in this inefficient supply chain is the production of word documents (again Agile folks stop shouting at the back) but in large scale organisations there hasn't really been a choice (anyone seen Agile in a 30,000 employee organistion done top to bottom?) and this supply chain has been repeated over and over again.

Now what should be the goal of the new supply chain for IT? Well taking a lesson from... IT.. the key here is going to be automate the wasteful human parts of the process, namely the human interaction steps that produce only intemediary information. This means our new process needs to be something like
So this means a few things, firstly we need a hell of a lot better tooling than the current approaches (and I include cue-cards and the post-it note mock-ups that people pass off as better than word), secondly that the people whose current job is just to act as an interface between the business and IT should be getting a little nervous, along with the people whose job it is to take architectures and requirements and create designs that are then handed to developers, and the final one is that the levels of skills of people needs to be raised a level. So while tools will automate out parts of the IT supply chain it needs a higher degree of skills than current exhibited by most people in these roles. No longer will architects have the comfort zone of designers who brush of the rough edges from their powerpoints, nor will system analysts be able to hide behind what the biz analysts create and hand-over. It means that there need to be tools that outline what the business wants (business SOA) and then people need the skills to enrich that with the right solution.

So in the future IT supply chain, and by that I mean the supply chain on the large scale not just for "agile" point projects. This is for packages, software development and the whole lifecycle.

So if you view your current IT delivery as a supply chain, where do you see your inefficencies?

Technorati Tags: SOA, Delivery, Service Architecture

SOA v POA, EDA, GDA

First of all a warning... I have an SOA hammer and maybe everything does look like a nail.

SOA - Service Orientation - I tend to see SOA has the bit where I stand looking at the toolbox wondering what I should use to get the job done, its key aim isn't to do the detail, its to help select the right tool to do the detail. In this SOA attempts to define the broad areas and capabilities, not to focus on specifics at the start. So starts by understanding the "What" of the enterprise, the broad "what do we do" questions, it then worries about "who" do we interact with and finally "why" do all these things work together. It doesn't deal with the "How" of implementation it just creates the framework within which that can be done.

There are other options as to where you start of course, and I'd like to start by saying if it works for you then fine, but I'm not liable to be joining you.

POA - Process Orientation - This is IMO the most broken model of all, often building on business school work of the 1990s it suggests that organisations are oriented around their processes and that by understanding the end-to-end processes. The problem is that businesses aren't oriented like this, processes go across many areas and process based implementation tends to lead to brittle and inflexible solutions. Organisations aren't process oriented. POA also actively prevents SOA as its a bugger to try and retro-fit decent service granularity into a process model, and equally if you just have lots of small components managed by big processes then its just Visual Cobol with components.

EDA - Event Driven - Identify the events first says this approach and then you can understand the business. The problem I have here is that this is to me just the capabilities bit of SOA, you need the encompassing service for two reasons. Firstly to provide context as to what the event is about and what is its surrounding business environment, and secondly to provide a place into which new business events can be added. Viewing businesses based on their events quickly creates large lists of events and its pretty tough to add a structure, even if you do event chaining, because it is just single events calling other single events. While not as bad as POA this approach still takes the approach that organistions operate based around single events rather than taking a more holistic view.

GDA - Goal Driven - Identify the business goals and you will then be able to move onto how to deliver against them. This isn't that bad an approach as Goals are often complex composite things for a business and they do help you understand the key drivers and principles of an organistion. The trouble is, particularly if you are more extreme and gather goals in a "flat" way rather than concerning yourself with the domain within which the goal is managed or attained means that you again have a set of singletons interacting which can make creating simple architectural solutions a bit of a challenge.

The good news is that all of these things are great second steps if you take a good business service oriented view. If you have one service that is best modeled by thinking of it as processes then POA within that service is a good thing. If you have a reactive system based around events then EDA will work within that service. If you have a goal oriented area that is best described in terms of its outcomes then GDA is right within that service. if its best to model Beliefs, Drivers and Intents then BDI is liable to work within that service. You could even say that SOA models the services, EDA the capabilities and the POA how some of those capabilities are implemented, but either way its the service that needs to come first.

EDA, POA, GDA and BDI and even OO are great ways to model how a service should work, or more specifically how the capabilities on a service should work. This is the key, EDA, POA and GDA are all aiming to define the capabilities that an organisation, enterprise or project should have, SOA aims to provide the mechanism for containment and abstraction for those capabilities and this is why it needs (IMO) to come first.

You don't start modelling an Object Model by listing out all the methods and attributes then trying to fit them into classes, you start with the classes then wonder what the methods and attributes should be, then worry about how to model their implementation. Its no different with SOA but operating at a business rather than a technical level. The first question is what are the containers, the buckets, the blobs... the services, then and only then should we worry about the capabilities, and once we have them we should worry about how you implement them.

Like with Web 2.0 v SOA its not actually one or the other. SOA provides the context, the others worry about the details.

Technorati Tags: SOA, POA, EDA, GDA, Service Architecture

LAMR will it catch on?

There has been a lot of talk recently about Ruby being the "next" greatest thing. Now I have to admit I've yet to have a decent play with it (which I will soon). There could however be an interesting challenge. In itself Ruby isn't too bad a name for a language, its different enough to actually come up as the first hit on Google, which is better than Microsoft's 1999 idea of COOL, which became C#. Now for those of us who know Ada the Ruby names a bit like a cheap nightclub single, but another open source name out there might cause some more issues, LAMP, Linux, Apache, MySQL, Perl/PHP/Python. Trouble is when you go Linux, Apache, MySQL, Ruby it becomes the slightly less useful "LAMR" and I can't quite see anyone standing up and saying "We are using a LAMR solution rather than the previous Java one".

Now JRuby (which is what I think I'll play with) could mean we have another option Linux, Apache, Ruby, Derby, JVM - LARDJ - its not programming in the small. Of course there is the slight problem that Derby is a bit rubbish, the other option I can think of is to go french with Postgres and get PLARJ

Glad I could help avert this marketing disaster :)

Technorati Tags: Ruby, LAMP