I've noticed with the rise of SOE (Intel, Service Oriented) that people who didn't know how to sell SOA are now hiding that by selling an even less clear Big Picture. SOE = SOA + SOI is a powerful message, but only if you understand what each of the elements mean.
SOE, its a powerful concept, but if you don't know what SOA is.... it doesn't help make it clearer.
A Simple blog about Business SOA and generally about how to drive IT from a business perspective. All opinions are mine and should be taken with a pinch of salt etc etc
Thursday, September 22, 2005
Sunday, September 04, 2005
SOA is it business or technology...
I'm personally getting fed up of seeing another article, or presentation from a vendor, which equates SOA with technology. Its very like those articles in the 90s which tyalked about a technology as being "OOD". Object Oriented Design was about a shift in how people designed systems, away from process oriented design, towards placing the domain model at the centre of any system. By making the domain model of primary importance in a system meant that you modelled the data and "things" of your environment how they actually happened. This was an immensly powerful metaphor that represented a shift in the way the average system was built.
SOA is a shift in a different area, its about changing the way we think about architecture. Its complete rubbish to say that SOA is an approach that started only with Web Services, as with OOD (which started with Simula back in the 60s) SOA is a concept that has been around for quite a long time, in fact it would be fair to say that most very large IT builds have been using Services since the year dot. So if SOA is an old architectural pattern why is it more important now? I'd say for two reasons, firstly because more organisations and projects are at a level of complexity where an architecture is actually required, and secondly because it is now simpler to translate that architecture into reality.
The key message on SOA therefore always has to be that SOA is about architecture, not about technology. And the purpose of architecture is to define the framework and context for the solution, this means that it must be focused on what the people who request the system want. This means it MUST be focused on the business.
SOA is a shift in a different area, its about changing the way we think about architecture. Its complete rubbish to say that SOA is an approach that started only with Web Services, as with OOD (which started with Simula back in the 60s) SOA is a concept that has been around for quite a long time, in fact it would be fair to say that most very large IT builds have been using Services since the year dot. So if SOA is an old architectural pattern why is it more important now? I'd say for two reasons, firstly because more organisations and projects are at a level of complexity where an architecture is actually required, and secondly because it is now simpler to translate that architecture into reality.
The key message on SOA therefore always has to be that SOA is about architecture, not about technology. And the purpose of architecture is to define the framework and context for the solution, this means that it must be focused on what the people who request the system want. This means it MUST be focused on the business.
Some recent presentations and publications of mine...
I've been doing more and more stuff around SOA recently, most of which to be honest can't be published yet. But there is some stuff I've managed to get out there into the public domain. Apart from the definition of service one in IEEE Software I've also been out with BEA talking about Delivering SOA (which got a nice review off Radovan Janecek Why SOA Works, and Miko over on Yahoo's Service Oriented Architecture group). There is of course the work around JBI, where its a shame that the Industry Panel video isn't available (every little bit helps the Google count though!). I'm due to be presenting at BEAWorld in London, which will include a bit more around how you really do SOA, and also coming up is a specific presentation around SOA and Local government for the folks at IBM. To add to the "its not new" stuff it was partly this that was the basis of a presentation I did with Steve Meyfroidt @ Saint 2003 on Java and Web Services we talked then about the fact that WS was only one part of SOA. Hopefully we will get some more stuff out at work over the next few months, as SOA is becoming an ever hotter topic.
The reason for lobbing this up is I'm hoping to get more time to write around SOA and its good to get the background material in early. Should Blogs have bibliographies?
The reason for lobbing this up is I'm hoping to get more time to write around SOA and its good to get the background material in early. Should Blogs have bibliographies?
Snake Oil SOA
I just read this piece of Snake Oil SOA from a VP of Web Services (one assumes describable via a WSDL), where there are a few choice phrases my favorite of which is certainly
I mean "An SOA can also handle more elaborate tasks. A retailer, for example, could reroute trucks automatically based on a weather report."
You can do that using a phone call, or indeed with quite a few packaged solutions. Its got bugger all to do with SOA enabling that, you can write a non-SOA solution to exactly the same problem. It would of course help if the industry analysts started calling people on this sort of "snake oil" approach to SOA and start pushing a fundamentally different message, namely one about SOA being an ARCHITECTURAL approach to solving problems that works from the BUSINESS perspective, thus enabling everyone to agree on the solution at all levels, and provide a mechanism for monitoring and managing the systems in a way that the BUSINESS wants.
I'm just picking on this one article because its pretty typical of the work that is out there, "Buy SOA, also solves baldness". SOA will fail miserably if it continues to be about the underpinning technologies rather than IT actually changing the way we work with our customers (the people who pay the wages).
The key technology behind an SOA is Web services, a poorly named term for easily identified and encapsulated business processes delivered over the webIf ever one sentence failed to describe what was important in SOA and what Web Services are then it is this one. Its an absolutely classic in the genre of "SOA will solve everything" and attributing that change to a technology (Web Services). This is exactly the sort of thing that is getting SOA a bad name with business people because its just another technology being thrust at them as a silver bullet for the enterprise.
I mean "An SOA can also handle more elaborate tasks. A retailer, for example, could reroute trucks automatically based on a weather report."
You can do that using a phone call, or indeed with quite a few packaged solutions. Its got bugger all to do with SOA enabling that, you can write a non-SOA solution to exactly the same problem. It would of course help if the industry analysts started calling people on this sort of "snake oil" approach to SOA and start pushing a fundamentally different message, namely one about SOA being an ARCHITECTURAL approach to solving problems that works from the BUSINESS perspective, thus enabling everyone to agree on the solution at all levels, and provide a mechanism for monitoring and managing the systems in a way that the BUSINESS wants.
I'm just picking on this one article because its pretty typical of the work that is out there, "Buy SOA, also solves baldness". SOA will fail miserably if it continues to be about the underpinning technologies rather than IT actually changing the way we work with our customers (the people who pay the wages).
OASIS standards and SOA
Whey hey we've joined OASIS. It actually didn't take much convincing and that means we've now joined both the JCP, OASIS and Open-group (the later had nothing to do with me). And already we've started getting engaged. Its amazing how many people are really keen to get envolved and help out. I've decided to look at two at the moment, firstly SOA Reference Model which is already well underway and I just want to understand more, the second (and for me most interesting) is the SOA Blueprints which talk much more by demonstration. One interesting point is that no-one knows which group is to define the actual structure for services and how the blue prints, especially industry ones, will be constructed. I'd expect that to be a keen point of debate in the coming months as structure is, to my mind, essential to a successful SOA implementation.
The great thing about OASIS is that its nice and public so everyone can see what is going on. Could be an interesting ride.
The great thing about OASIS is that its nice and public so everyone can see what is going on. Could be an interesting ride.
Subscribe to:
Posts (Atom)