More than this, I think "applications" are still important in SOA as an aggregating mechanism for "services".
To "IT enable" any large undertaking will take many thousands of even coarse-grained "services" never mind all the supporting infrastructure. I just don't think we have the ability, time or energy to manage this effectively. Whilst all these "services" might be "loosely coupled" (in some sense), the effect of such a large number of services interacting with each other is an immensely complex system made up of many (albeit small) dependencies. To help manage these dependencies and their inevitable change and evolution, I think we will both want and need to group them together into bundles of closely-related services that can be treated as a single unit - an "application", if you will. The obvious connecting point for such closely related services is the shared domain data store. That is, you might expect to bundle services together based on their need to access and manipulate information from domains such as "customer", "product" and so on. The main building blocks of your IT architecture are therefore applications consisting of bundles of services in each of the required information domains. But rather than being solid and monolithic "bricks", such building blocks are more like the children's toy "stickle bricks" (http://www.flairplc.co.uk/pages/stickle.shtml) with the connectors of the bricks as the services. -Mike. --- In [email protected], Stefan Tilkov <[EMAIL PROTECTED]> wrote: > > On Nov 23, 2006, at 4:01 AM, Todd Biske wrote: > > > Your architecture may be SOA-compatible if the term application has > > been removed from your company's lexicon. > > I think I agree with your basic point - you should be developing, > deploying, versioning, managing, buying, outsourcing services, not > applications. But in the end, something has to actually *use* all > those services. That's still an "application" in my vocabulary. > > Stefan > -- > Stefan Tilkov, http://www.innoq.com/blog/st/ >
