Assess
A typical IT organization will have thousands of assets that have accumulated over the years. Assessing which of these assets are of value to the organization moving forward must incorporate both business and technical perspectives. Issues that need to be taken into account during the assessment phase include:

As you begin, remember the 80/20 rule; some SDAs are obvious candidates for your initial cataloging efforts, while other marginal assets are best left behind.

How does our example component fit against our assessment criteria?

Based on our assessment, it appears that our currency conversion component is an important asset that should be preserved and managed into the future. This leads us to the next stage of our model-based approach.

Build
In the build phase, our task is to align our essential SDAs with our business roadmap (i.e., our business architectures and models describing current and future business requirements to be placed on the IT organization). The end result of this effort is a ready reference that gives us the ability to see what aspects of our business architecture are already supported, to identify redundancies, and to see where gaps exist. Ultimately, effective use of this reference model will enable us to build Web services that present the right level of information and interact with the right underlying business systems.

Our business architecture team has been busy defining requirements for our next generation of e-commerce systems, and they have taken the next step to express these requirements in the form of a UML reference model. Figure 2 illustrates a portion of that model that is pertinent to our example component.

 

Each class within this UML diagram represents a coarse-grained reference component that supports one or more interfaces. If we look into the Currency Exchange System component in more detail, we see that its two interfaces define a series of operations as shown in Figure 3.

 

The operations defined here can be mapped against the methods defined by our EJB (see Table 1).

 

Notice that some of our reference component methods are not directly supported by our EJB, and also that some of the capabilities of our EJB (e.g., our ability to configure conversion strategies) aren't reflected in our reference model. However, our mapping does show that we have a strong affinity between our desired business capabilities and this existing SDA.

Locate
As our development team is tasked to build out portions of our next-generation business architecture, they will take advantage of our previously built business reference model to search for candidate SDAs that can help them do their work more efficiently. Let's assume that our team has the responsibility to build out a Web service supporting currency conversion. Their work activities flow as follows:
1.   They begin their work by identifying the portion of the business reference model that applies to their project - specifically, the Currency Exchange System.
2.   They then investigate the services and operations defined by that reference component.
3.   For the set of selected operations, they initiate a search against the underlying SDAs mapped against the reference model. In this case, they discover our CurrencyExchange EJB.
4.   The team then retrieves various artifacts as part of their evaluation process, ultimately concluding that they can take advantage of this asset in their Web services development project.

How will they investigate the components and services associated with this model? While some groups have built reference models to asset mappings through spreadsheets and other similar tools, an SDA mapping and discovery engine can speed and improve this process dramatically.

Depending upon the area of the model being investigated, our team might find multiple assets that support a set of business capabilities, at which point they need to determine if they should select one of these assets for future development or if they need to provide an encapsulation service that binds all of the existing assets together and ensures consistent data and behavior across them (if, for example, multiple customer information systems must be supported because of business merger activity in the past). Or they might discover that no existing assets support a portion of our model, indicating that "green-field" development is needed to support some expanded business capabilities. Regardless of the outcome, our team has a better view of what is available to them to use in the next stage of the process.

Employ
The employ stage is where all of today's "whiz-bang" Web services tooling comes into play. With our Currency Exchange example, we will likely retrieve our EJB .jar file from its repository location and deposit it into a project within our IDE of choice, then use that IDE's Web service-generation capabilities to convert our SessionBean interface into a Web service with an associated WSDL file, Java client proxy, and other artifacts.

As part of the employ phase, we have some decisions to make:

Ultimately, as these newly built Web services are created and deployed, our team will complete the life cycle by feeding them back into their catalog, mapped against the business roadmap for which they were built. These Web services now become part of the developer's everyday toolkit - resulting in faster, higher quality, less expensive application development and integration.

Summary
Taking the time to put our Web services and the underlying SDAs that already exist in our infrastructure into an IT library will ensure that the services we produce will provide true value to the business and not introduce more technology for technology's sake.

References