Robin, let me clarify a little my position being based on your comments. 1) you say "quite never possible because change is not often predictable" while I say that SOA creates situation where unpredictable changes in the business requirements are seldom and caused by fundamental changes in the business model. All other changes are predictable because they are derived from the business model of the enterprise/division. Another thing is that the business client (unless it is in service-oriented business model itself) never articulates the requirements capable to accumulate a change, and IT does not dare to look further than what's required this moment (until IT is organized on SOA principles). Example from my industry: regular business requirement says something like "implement 'sell' action for an ISA fund'. If I am doing SOA, I will implement a service which can perform 'sell'/withdraw function from a fund and accompany it by policies that constitute ISA constraints. I will do this because I know my organisation is in fund management financial service market and tomorrow there will be a need to perform the 'sell' function on another type of fund. Such future requirement will mean to me just adding another policy (ies) to constraint a fund into particular type. That is, I KNOW what my business CAN/MAY want until it does not change its business model (you can imagine how frequently such things happen...) 2) I do not think a business has any reusability for relatively complex things. Why IT has to have it in SOA? The smaller and basic an operation is, the more reusable it is but is it a service (which is define as coarse-grained entity, i.e. far from basic)? So, I do not see much agility through reusability because the latter is rare in the business itself. It looks to me that the agility comes from service extendibility rather than from reusability (I know what many people would say to me at this point). Extendibility, in this context, means that the same service may be used for different things that belong to the same category/domain (as in the example above). Nevertheless, if a service is generic enough to accommodate 'different things of the same type' or fine-granular/basic one, the reuse of it in different business tasks REQUIRES full re-testing, even if no changes are made. The reason for this is in the change in the service execution context. That is, the results delivered by the service may be inadequate to new context (e.g. because of a new policy the service did not consider when it was initially designed and build). For example, a service reporting personal financial data may be used across all States (except for California, probably) but it may not be used across boarder between Singapore and USA, or Singapore and Vietnam (because of Singapore low). - Michael
Robin <[EMAIL PROTECTED]> wrote: 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. > --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos.
