I think that designing extensible services/operations, I mean, services able to offer more functionality without breaking the compatibility, is key to a successful SOA over time. It's unfortunately quite never possible because change is not often predictable. In that kind of situation, techniques like type versioning will help in managing change in a SOA.
What I understand from your answer is that there is probably more potential in the ad-hoc composition of basic operations for achieving business agility. I agree. But when we do an ad-hoc composition, it's not reusable by definition. It's the same problem again at a different level. If you have 2 look-alike compositions for 2 different use cases, will you design one generic composition (reuse) or not? Not a black and white kind of situation of course but the choice that will be made here might influence future agility and costs. Robin --- In [email protected], Michael Poulin <[EMAIL PROTECTED]> wrote: > > When we are talking about business agility, it would be useful to define 'business agility' first of all. > > I do not try doing this and have just a scenario. Let's assume a business situation in the market has changed and the business wants quickly react to this change. The reaction may be expressed in the form of a) changing existing business functions; b) creating new business functions; c) something else (?) > If the IT offers just SOA based implementation of business functions, it is not enough for quick changes of new creations. That is, IT has to have, e.g., services that are smaller in the scope than a business function; it may be a business operation. It is assumed that existing business functions are composed of business operations. So, new function should be just a new composition of operations and a changed function is the changed composition (for simplicity). This looks like a lot of reuse. > > What the probability of a chance that a change or new feature of the business service cannot be expressed a composition of already existing services but require a little modification of the service? From another perspective, what granularity the service has to have to keep aforementioned probability as low as possible (otherwise, a small change may cause global retesting and/or modifications which is not acceptable)? What is wrong with programming language API? They are reused a lot... > > How many reused business functions or operations one can fined in an enterprise? If SOA implements business model and SOA is considered as a straight forward way to agility, why we are talking about a reuse? Reuse was/is the marketing "talk" performed by IT toward business. It has quite little in common with agility. However, if the service is designed for extendability with coarse-gained interface and without explicit operation signatures (but in container/command/document manner), it is very easy and quickly to change the service w/o breaking service contract with its already existing consumers. This is the agility with changing business needs, I think. > > - Michael > > Robin <[EMAIL PROTECTED]> wrote: <Improving the reusability of business process and technology assets > helps businesses get to market faster, reduce costs...> > Really? > I think it is over-simplistic to think that increasing reuse will > reduce costs and will help business to market faster. > > I have been blogging some time ago about what I call The Paradox of > Reuse that is: "as much a service or a component is reused, as much > the risks and the cost of changing it are important." > http://blogs.ittoolbox.com/eai/applications/archives/the-paradox-of-reuse-4561 > > It means that reusing a component or a service results in an increase > of dependencies between systems, departments or teams. The > dependencies between systems is something that requires a high-level > of maturity and governance in a large company to deal effectively with. > > If reusing a service or a component means that you don't have to write > and maintain the same code twice, it now does mean that you maybe rely > on someone else to change this service (or create a new one) to match > your new, ever changing, requirements. > > The previous sentence might be interpreted positively or negatively > depending on the context. In highly regulated IT departments where > Enterprise Architecture is strong (think about Swiss banks for > example), that's business as usual, they believe in that. While in > other companies (I've got plenty of examples but I won't name them) > the only option to deliver on time and budget might be to redo > everything and not rely on other teams for delivering something useful > for your project. > > Sounds familiar? > > I am sceptical about the equation: more reuse = more business agility. > I think that's possible, I've seen this, but maybe not applicable to > every company today. > > Robin > --- In [email protected], "Gervas > Douglas" <gervas.douglas@> wrote: > > > > <<Improving the reusability of business process and technology assets > > helps businesses get to market faster, reduce costs and achieve more > > consistent results. This important concept has recently been receiving > > attention because Service Oriented Architectures (SOA) are enabling > > businesses to achieve much more frequent and extensive reuse of > > business services, software and data. > >...... > > These modular components can be reused in other situations and for > > other departments or to meet other business needs. When this all comes > > together a business can expect to benefit by increasing its speed to > > market, trust of information, and flexibility to change.>> > > > > You can read this at: > > > > http://www.it-director.com/business/content.php?cid=9352 > > > > Gervas > > > > > > > > > --------------------------------- > We won't tell. Get more on shows you hate to love > (and love to hate): Yahoo! TV's Guilty Pleasures list. >
