This is a pretty good article, however, they miss out on one important factor: Marketing. I still refer back to a presentation I heard at SD East way back in 1998. Unfortunately, I don't recall the speaker, but he had established reuse programs at a variety of enterprises, some successful and some not successful. He indicated that the factor that influenced success the most was marketing. If the groups that had reusable components/services/whatever were able to do an effective job in marketing their goods and getting the word out, the reuse program as a whole would be more successful.
This article focuses in on governance, which is clearly an important aspect, but focusing in on governance alone still means those service owners are sitting back and waiting for customers to show up. While the architectural governance committee will hopefully catch a good number of potential customers and send them in the direction of the service owner, that committee should be striving to reach "rubber stamp" status, meaning the project teams should have already sought out potential services for reuse. This means that the service owners need to be marketing their services effectively so that they get found in the first place. I imagine the potential customer using Google searches on the service catalog, but then within the service catalog, you'd have a very Amazon-like feel that may say things like "30% of other customers found this service interesting..." Service owners would be monitoring this data to understand why consumers are or are not using their services. Interestingly, this is exactly what companies like Flashline and ComponentSource were trying to do back in the 2000 timeframe, with Flashline having a product to establish your own internal "marketplace" while ComponentSource was much more of a hosted solution intended at a community broader than the enterprise. With the potential to utilize hosted services always on the rise, this makes it even more interesting, because you may want your service catalog to show you both internally created solutions, as well as potential hosted solutions. Think of it as amazon.com on the inside + with amazon partner content integrated from the outside. This is a great conceptual model, however, I don't know what the potential of this would be today. How many enterprises have a service library large enough to warrant establishing this rich of a marketplace-like infrastructure? If you go beyond service reuse, however, and include shared libraries, and even shared infrastructure, now the inventory may be large enough to warrant an investment. Now time to copy and paste this into a blog entry. -tb On Mar 30, 2007, at 4:06 AM, 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. > > One of the main drivers for the adoption of SOA is the business need > to be more flexible and responsive to change. Change is part of the > business ecosystem. A long time business partner can suddenly become a > fierce competitor as the result of a merger. The dynamic between > partners, suppliers and customers is in constant flux. A business > loses the ability to adapt if its software and supporting IT > infrastructure is inflexible. And to become more flexible, a > comprehensive strategy for reuse is needed. > > The Nature of Reuse > Reuse is by no means a new concept in IT. It has been tried in various > ways and at many levels from the use of source code libraries to the > building of software components within object oriented architectures. > When left to their own devices, experienced developers usually find > ways to reuse the code they have previously written or even use open > source code that is freely available on the Internet. But such reuse > is never consistent throughout software development teams and the IT > industry has never implemented reuse effectively in this way. > > Within the SOA environment reuse is different because it is woven into > the architecture. Components of models, software, rules, and data are > made available for reuse in a way that ensures their accuracy, > consistency and predictability. This amounts to the business > governance of all the reusable assets. It isn't easily achieved, but > it is a worthwhile goal. > > The reuse of IT assets is not so different from the reuse of > components in manufacturing. Automobile manufacturers do not make a > different engine for each model of car they sell; they make a small > range of engines and install them in a wide variety of models. Once a > new engine has been tested and documented, its reuse in a wholly new > model gets the new car to market much faster. The same is true of even > quite small components. Nowadays cars are designed to maximize reuse > at every level—and to everyone's benefit. And just as the reuse of > components in a production facility needs to be managed carefully, so > must the reuse of business services in a SOA environment. Reuse > without governance can be more destructive to the business than no > reuse at all. > > Hurwitz & Associates has identified three major risks to the business > associated with reuse: > > * Poor Process. This typically occurs when the level of > collaboration between business and IT is inadequate. Within SOA the > business and data services should accurately represent the business > processes followed by the organization. Collaboration between business > and IT needs to result in the business having a clear understanding of > which definitions of data make sense and when to use them, how to > apply rules and what level of granularity is appropriate for business > services. Effective reuse will be much harder to achieve unless there > is a framework in place that ensures that business and IT are singing > from the same song sheet. > * Poor Management of Code. Business processes are nearly always in > a state of flux, so it goes without saying that the software code that > codifies a specific business service may also change frequently. When > software components are changed then the changes apply > everywhere—often resulting in unintended consequences. Clear ownership > of reusable software/business services needs to be agreed to among all > business users. A strategy for reuse of business services must include > an approval process for changes which begins with the "owner" of the > business service. > * Lack of Overall Control. Without a structured process around the > governance of SOA, it is difficult if not impossible to maintain a > consistent set of rules for the enterprise as a whole. What if, for > example, each business unit in a transportation services company > follows a different process for extending credit to customers? Let us > imagine that the business wants to create a shared business service > for this process. The following questions must be answered: Who owns > the business process and how will changes be controlled? Who is > responsible for maintaining the consistency and quality of a shared > data source on customer credit information? > > The first step to reaping the rewards of reuse is to understand the > risks involved. In order to ensure a successful strategy for reuse, > business and IT must first collaborate to understand, evaluate and > model the business process at their organization. The level of reuse > that can be achieved within a SOA environment increases when a > comprehensive approach to governance is applied at all levels of the > organization. > > When you build business services based on services oriented approach, > you create modular and standardized building components that can be > linked together in various ways following a predictable set of rules. > 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 > > > > > Yahoo! Groups Links > > > [EMAIL PROTECTED] > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
