The business value of EA only becomes truly clear (beyond simply reducing costs in the IT infrastructure) when you begin to think of SOA as a strategy for implementing EA. Then the architecture effort has a built-in business goal: create an architecture designed to deliver services to the business in terms it can understand. Simply put, it's the first technical concept I've seen in ten years that actually drives alignment between IT and the businessWhich I heartily agree with and indeed in general the links are full of some pretty good advice. Oh and of course of bad advice like ESB is the start. The clue is, as Roy Walker would say, in the question.
The starting point for SOA, for Service Oriented Architecture?
That'll be the Services, the ones that deliver services to the business in the way it understands.
So to be really, really clear. The starting point for SOA is
The Services
The next up comes the architecture.
Technorati Tags: SOA, Service Architecture
9 comments:
Hi Steve,
I think the starting point for SOA are business events.
See this link to a blog of mine, where I tried to explain:
http://soa-eda.blogspot.com/2006/08/are-you-old-style-or-new-style.html
Jack
I'd disagree in part because the events need to be happening somewhere and that somewhere is a service. In the SOA method bit it lays out three stages What (Services), Who (External actors), Why (Events and Drivers) in that order. If you start with Events then its got to be an event oriented architecture and I'm not sure how that approach would really scale without the boundaries given by services.
Hi Steve,
You are challenging me. I like that.
I think events happen in the real world. And I think that should be the starting point of a SOA-design. Real-world events are the triggers for the business processes by nature. When you support a business process with IT, then of course you must get the event in your IT-system. You may call that a service, but it can be all kind of software components (even hardware). What we do is starting with modeling the events. We describe events in canonical formats and we publish the events in a "global dataspace" (implemented by an ESB). We use web services interface technology to publish these events. Again, you may call these publishers services, but I'm not sure if that always appropriate. And yes, the publisher uses a web service interface. But I wouldn't call that a SOA yet. In my opinion SOA starts with handling the events, using generic functional building blocks.
Modeling events is what we call an event-driven architecture architecture, the layer between the real-world events and artificial IT-systems (SOA). So (business) events are our starting point It's the way we obtain optimal alignment our business and the supporting IT-systems.
By the way, I like your blogs.
Jack
Another post on the topic. I agree - you start with the services!
http://blogs.ittoolbox.com/eai/business/archives/where-to-start-the-soa-transformation-10343
Jack,
The reason I'd have to say that events shouldn't be the starting point is that isn't the real starting point. When you first wander into organisations the events LIVE somewhere in that organisation. Receiving an order lives in sales, and receiving a shipment lives in the warehouse. The first elements you find therefore are the different areas, which I'd argue are the highest level services.
I'm talking here about modelling the business well before you start worrying about the more technical elements like the events. Hence the services.
My view is that EDA is just one of the implementation options that works for certain parts of the business, other elements like BDI (goal driven agents) are better able to describe other bits of the business, but services hold it all together.
Steve
PS Isn't canonical form a bad idea?
Hi Steve,
I understand what you mean. The clue is that you see events as a technical implementation, whereas I'm thinking of real-world events. Business events are the interesting real-world events what a company wants (has planned, is forced) to respond to. The respond to business events is the business process, which can generate new business events, and which can change over time. Interesting is that business events are very stable, while the way you respond to them (business processes) is not.
What I believe is that you can only start modelling business processes when you know the business events you want to respond to. You can only start modelling SOA's (which might be seen as a way to model business processes) when you defined the business events.
So in my vision events are not technical elements at all. Fortunately we have an ESB to capture the business events and publish them to all interested business processes. And to build an environment to monitor the state of our business in real-time. Yes, that's technical.
Jack
PS Canonical formats is another story. At Dutch Railways we insist on using canonical formats of the captured business events. I'll publish a blog on that shortly.
Hi Steve,
As the canonical data modeling (CDM) architect at the Dutch Railway Company I was triggered by your question about whether a canonical form is a good idea or not.
I'm interested in what makes you doubt. Can you tell me?
BTW, I just started a blog of my own, planning to write about the fascinating world of data, and therefore about CDMs as well.
http://senseofdata.blogspot.com
(don't know yet how to add a link here, shame on me!)
Jack,
I'm not thinking about the events as technical things, I'm thinking about them as being real-world capabilities that the business has (which when instigated have real-world effects) hence the reason (as per the OASIS SOA RM) that they need to be invoked VIA a service. When you have a "Market product" or "receive product" event these are undertaken by something and instigated via something. That something is the service.
Hence in my view you have to model these elements first, then the events/capabilities because the organisation may want to do more things than it does today, but within the bounds of what its already does.
Maarten, I'll lob up a brief post on canonical form and why I'm not a fan.
Its a very nice blog for...
architects in bangalore , architects in bangalore , interior designers in Bangalore , interior designers in Bangalore , architects in bangalore , architects in bangalore , interior designers in bangalore
Post a Comment