Sunday, January 29, 2006
The vendors however are continuing to concentrate on the technical elements, which as Miko pointed out at the recent Oracle EA club are the low cost and low impact challenges, while businesses and systems integrators are focused on the human and governance challenges of SOA. Previous IT waves have concentrated hugely on improvements in technologies, the difference being ERP which started to concentrate on how business operated. SOA, when done well is focused hugely on the actual delivery of IT and projects rather than on the technology in that delivery. Which means the skills are not around technical considerations but the human ones.
SOA-RM and the SOA Adoption Blueprints both consist mainly of technology delivers rather than vendors, who are concentrating more on things like WS-Transaction et al. So without a focus on IT delivery can vendors ever hope to deliver on SOA?
Wednesday, January 25, 2006
During a rather nice meal in London with Miko Matsumura of Infravio the service governance people he highlighted one area of the coming SOA challenge that I hadn't really thought about. Namely the challenge of governance rules becoming applications in themselves. Its one of those things that become obvious when you follow the trail down to the end but its still a different way of thinking about SOA.
Basically the point is that while Service governance is simple policy (e.g. WS-Security) or about protocol then its all nice and simple. When it becomes about rules of governance, e.g. only people with authority X can update this service or even "these fraud validation rules must be done on each inbound transaction" then it ceases to become simply about policy and more about actual business logic and function.
So the question basically is, when does policy become business logic and what is the best way to define, build, deploy and manage a governance centric service? Is "Payment" the functional service and "Payment with fraud-detection" the enterprise service?
Friday, January 20, 2006
Following up on an earlier post its worth going over the difference between a business service bus and an integration service bus. There are a whole different bunch of vendors out there selling "Enterprise" Service Bus products, in reality these are normally products aimed at creating services out of existing systems (Integration) or at providing accessibility and management to more business oriented services. The problem is that people are confusing the two areas, which is very dangerous if you want a successful project. Integration products are about adapters, transformation from multiple data format and generally trying to squeeze that damned external application into a shape that the rest of the world can use. These are about managing events to and from these systems, short life processes and a real concentration on shifting data, enrichment and all the trimmings.
The otherside of the story is the business side, this is about policy, management, control and business function. This is the XML centric part of the world, mediation and minimum transformation, versioning and of course enabling connection to be done in differing ways, to me this just means reliable v non-reliable and using queues v HTTP or email rather than trying to get it out of an ERP specific format or a database.
What isn't in ANY of this is business process, that is a different thing again, in fact business process is about BUILDING services, normally high level ones its true but services none the less. Business process is an application thing, not just a layer across the enterprise. As tools begin to enable more and more to be done its getting more and more important to be clear in your architecture what is done where, otherwise you end up having one almighty blob that you christen as you "SOA ESB" and two years later you curse as Project X which gives you no clarity as to what is being done where.
So basically don't buy one ESB to fit everywhere, make sure you think about the specific challenge you are facing and separate integration tasks from business service tasks, and keep business process out of both of them.
Saturday, January 14, 2006
This SOA reference model works therefore from a long term perspective with a good clarity on principles. Its fairly interesting to look at the membership list this is a specification created by people who deliver SOA.
(updated to include the right link for the PDF!)
Wednesday, January 11, 2006
SCA is in someways an extension of the work that BEA did with Beehive so I'd expect them to be able to move relatively quickly, as should Oracle as they are moving from a similar technique using WS-IF, which IBM used in the previous version of their product too.
Strong technology with a very devent future.