Worst description of Java Beans ever?

JavaBeans is a component object model with API's that extend Java's reuse capabilities by enabling third parties can create applications from reusable components. JavaBeans is the Java analog of Microsoft's ActiveX, and of OMG's CORBA. Unlike ActiveX, JavaBeans is intended to be platform-independent.

By an assistant professor at the University of Virginia.

Genius

Technorati Tags: Java

Enterprise SOA Adoption strategies

Whey hey I've had a book published by the nice chaps at Infoq. Free download if you register, but of course its much nicer to have a hardcopy on your shelf at home. The book is an SOA book, not a SOD IT book and I've tried to cover as much as possible on how to define your SOA and the potential impact that this could have.

Comments, critisisms, recommendations and requests welcome.

Technorati Tags: SOA, Enterprise SOA, Service Architecture, Service Oriented Architecture

Why Best of Breed and loose coupling doesn't always work

Over the weekend there was another great example of why best of breed software choices aren't always the smartest. It demonstrated why the ability to work together to get something done is more important than just lobbing together the best things you can find. Sure the Americans on paper had the better players... but the Europeans had the better team, much the better team as it turned out.

From an SOA perspective this is an important lesson, it means that its actually the links between services are critical success factors, rather than just the services themselves. When people talk about getting in lots of best of breed services and just orchestrating them together they are missing a key point about cohesion.

Loose coupling isn't the best thing in the world all of the time. Sometimes things are better if they are naturally cohesive and actually have a high degree of coupling. This can make it easier to get them to work together and actually deliver more value because of this cohesion.

So be very careful when obsessing about loose coupling or using only "Best of Breed", think about the right level of coupling and the services that work for you.

And remember... don't listen to Accenture, when doing SOA its better to be a team than a tiger.

Technorati Tags: SOA, Service Architecture

SOA RM - exit poll indicates its going to be a standard

Okay there is still a few days to go on the vote, but the standards vote for the SOA Reference Model has passed the threshold it needs to become a standard, so as long as nobody votes "no" its going to make it. This means that for the first time in the history of SOA there is actually a standard that isn't about shifting XML from one place to another but is actually about the key concepts of SOA and the guiding principles that people applying SOA should abide by.

Phenomenal achievement by the team and in particular the chair who herded the cats, nice one Duane.

If you are doing SOA and you haven't read it already, then you really are causing yourself a lot of pain when you are trying to explain SOA to people. Get yourself a copy of the SOA Reference Model and have a read. If you use this as the definition of SOA in your organisation this gives you a much firmer base both with the business and IT and stops squabbling over minor points of detail. When you do use it, let the group know, we'd appreciate the feedback.

Whether you are doing WS, REST, Business Service Architectures, Shared Services or People Services the OASIS SOA Reference Model can define the basic principles in a consistent manner.

At last we have a standard for SOA that is about SOA and not about the technology.

Technorati Tags: SOA, OASIS, standards, Service Architecture

SOA Meeting Rules

From Steve's book of applying the blindingly obvious to SOA...

1. Meetings shall have an agenda which will
   
1. Identify which services an item refers to
2. Have a proposed lead for the item
3. A RACI for each item
   
2. During meetings only people who are RAC in the RACI can talk on that item, if you are "informed" shut up
3. Minutes will be kept for the meeting with actions assigned to both services and individuals these will be translated into work tasks or bug reports associated with the service.

All I'm really saying is that SOA doesn't mean that you can just get a bunch of people in a room without an agenda and hope to actually acheive things.

Technorati Tags: SOA, Service Architecture

Dark SOA revisited

Having been involved in a couple of REST v WS discussions recently, I've decided that not only does Dark SOA really exist, it is actually more like a black hole than Dark Matter. We all talk about business agility and flexibility, but then start arguing over the technology and pretty much forget about the business side of things in a mistaken belief that technology is what they wanted in the first place.

This attractive force of desiring to focus on technology rather than the business is really damaging to getting SOA delivering on the promises, its really creating a black hole into which IT people continue to fall while still protesting that everything is fine.

If SOA is technology then its another TLA and another black hole down which money and broken promises are thrown. And while its kind of interesting to watch these projects and ideas fall to their deaths and be compacted down on top of the previous generations of IT to form a super dense impenetrable IT estate, this time with XML as well, its not much fun when I realise that I'm probably going to have to work at some of these companies at some stage in my career.

Technology SOA is Dark SOA, its black hole creating supermass that brings everything down with it.

The clue is in the question folks, want business agility? Focus on the BUSINESS

Technorati Tags: SOA, Service Architecture

Why REST v WS is irrelevant in two pictures

So here is a simple picture to describe how I think people should expose internal functionality to external consumers. There are a couple of things here

1. Internal Services have "business" interfaces, these are what the developers, analysts, architects and the business understand in terms of the capabilities being offered. This is the "code" interface (not XML)
   
2. NEVER EVER EVER expose this directly. This means you now have tightly bound your internal code to your external customers

So the first thing is to add a Facade where mediation can if requiredbusiness style interface, its server side and its still not in XML.

Then you sit down and decide how to expose it externally. Will it be REST, will it be WS? Will you decide to use pub/sub notifications, will you decide to use flying monkeys? Quite frankly who cares?

This external service is the one where you will decide to plump for WS or REST, or hell why not go mad and support both. Now converting a business interface into REST probably means having multi URI points to represent different managed resources, but that isn't exactly difficult either.

All we nmultio do in this case is to run three external interfaces, which are just doing data exchange, there is no actually functionality here as that lives down in the backend.

This way as our backend functionality changes we can prevent our clients having to directly upgradebackendan in fact use thisbackendch to support multiple interfaces concurrently, based on a single business service implementation.

Equally we can make changes to the external interface, to add security (always a good idea), to optimise the interface or to move it from a custom schema to an industry standard one. The important bit here is that you've modelled your business service correctly and it has the right capabilities which you are then choosing to expose. The mechanism that you use for exposure isn't important at all and 100% isn't where the flexibility comes from.

Flexibility comes from that internal service being able to react to the business and change with the business. That is the architectural challenge. REST v WS is an implementation challenge, which is something to worry about (its part of SOD IT) but its not what gives business agility or flexibility.

I'd really strongly recommend that people always use the pattern above, its saved me lots of pain over the years.

Technorati Tags: SOA, REST, WS, Service Architecture

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