you keep repeating this and different groups take ownership of those flows.
therefore some flow that generates value for the business is directly tied to its technical implementation
operation and ownership. in a very specific way.
the organization as a whole has an architecture group and they try to flesh out things that seem to be actually repeating in the business and sees if it is financially/technically feasable run it themselves and provide it back to all the groups as a service.
at the end of the day that might make it way easier to chop up or merge your business with others because the technology flows map closely to the flows of the business.
you could draw a circle around some groups and put a Security Token Service in front of them.
you can move some of those circles behind new firewalls and put service bus between them.
you could host entrypoints on premise with Dublin(appfabric)
you could imagine a set of tools built on Oslo modeling that lets you "move these circles and thier components around from on premise to the cloud and autoprovision the S+S of it all.
i call this Business Oriented Architecture or Just In Time Service Oriented Architecture lol.
dude im feeling you on your SOA rant... i dont think you can sit down and define things at that scale ahead of time like that. weve all had our bad moments when we try to over architect something so it can be reused in many different ways yada yada.. frameworks classes etc... creating a SOA is like creating a platform for your business to run on....Microsofts business model is creating frameworks and platforms... not a regular old company.
When we create software its supposed to server a specific purpose.. overgeneralizing it gives you flexibility but moves you away from that purpose.
SOA is the ultimate overgeneralization?
what makes it worse than the application level is that in SOA everything is so distributed
and things are changing, competing interests, technology evolutions, politics and financials of the system etc etc...
I think the way it should be done is more like .... i dunno...
lets call it Just In Time SOA.
Lets say you are in business and some market change happens you want to take advantage of.
This might require building/buying/reconfiguring existing systems and tying them all together to form some chain of business capabilities that I.T. makes go.
you build that in the SOA way.
Using the best technologies available at that time for each of the components.
Somegroup owns that
Recently a lot has been written about SOA's failure to deliver results and ROI. Wherever you turn you will find blogs, articles and opinion pieces saying what amounts to "At last the snake oil is exposed. Flush and lets ...".
And that's thing thing isn't it? Lets what exactly?
Lets go cloud computing? Lets go Web 2.0? Lets go mash-ups? Or whatever. Thing is will any of these turn out any different to the perceived failure of SOA in 5 years time? Why would they? Most of these concepts borrow from SOA ideas which were based on ideas that came before that.
SOA/Distributed-computing/Web 2.0/Mash-ups/Cloud-computing/yada-yada-yada all need an architecture rather than the "let's go buy some software, do our project and be heroes". In fact this attitude is what created the mess that SOA et. al. was born to fix.
* Most organizations that I've seen with are using service-oriented middleware to do integration (SOI rather than SOA). Very few companies are actually re-architecting their systems...
The SOA goal however, needs to be the rationalisation of IT. Effort needs to be applied to streamline the business process by reducing the complexity and the application and data layers.
I am reminded of an old adage "a poor workman blames his tools". Doesn't matter how good the tools are - if you start building without a planed architecture - the SOA journey will end abruptly!