In this chapter the implementation of use case will be elaborated further. We will highlight additional implementation requirements and the changes required to the Asset Lifecycle in order to gain maximum benefits from the introduction of Governance. Furthermore, the chapter will deliver a how-to guide into performing an initial configuration of OER.
While this chapter assumes that the Harvester Solution Pack and the AIA Pack have been installed, we will defer the implementation of these components until the later chapters.
As described earlier in Chapter 2, Implementation Use Case, Weir & Bell Telecoms faced several challenges with their initial SOA implementation. A fundamental challenge identified by the SOA Assessment exercise was around the lack of visibility of existing SOA Assets at design time resulting in the duplication of Assets. The reason is simple, if an Architect or an SOA Designer is unable to view existing services when producing a design, chances are that the functionality will be duplicated across the enterprise leading to unnecessary effort and redundancy. Other challenges such as lack of team collaboration and lack of methodology contributed to the issue of visibility.
This exact situation occurred at Weir & Bell Telecoms. The company had around 60 existing SOA Composites at the time of the SOA Assessment. The capabilities delivered by these services were mainly around the supply chain and order-to-cash. For example, purchase order creation, credit checks, invoicing, inventory management, fulfillments, and others. The SOA Assessment also discovered plans to create around 80 new services across the enterprise to address new business requirements for the same supply chain and order-to-cash processes.
Taking a step back after the SOA Assessment, the Architects started to analyze existing services against new requirements to see if the existing services could be enhanced or augmented to satisfy the new requirements. The results were startling!
The SOA Assessment had concluded that the cost of delivering a new SOA service from the moment of its conception to the production rollout was around $32K.
Applying some simple math to these numbers, the Architects calculated the cost of the new development effort as follows:
$32K (cost of delivering a service end-to-end) X 80 (new services) = $2.5 million Dollars
Thus it was clear that it would cost Weir & Bell Telecoms around 2.5 million Dollars to deliver the new functionality. The problem was no one could easily determine how much of that functionality already existed in the current estate since visibility of existing services across departmental boundaries was hazy to say the least! It was clear from the assessment that apart from an outdated Excel document, the functionality supported in the existing SOA services was not captured anywhere and the Architects had not referred to this document when specifying new services.
After undertaking a quick analysis of the new service requirements versus what was known of the existing services, the Architects were able to conclude that there was an opportunity to address around 40 percent of the new requirements by the re-use of existing Assets. However, this is not an exact science and it is recommended that one has to aim at being broadly right and not accurately wrong.
From this quick analysis, the Architects were able to calculate the potential savings of re-use as follows:
$2.5 million Dollars (approximate calculated cost of new services) X 40% (of potential savings if re-use is enforced) = $1.02 million Dollars
The case for enforcing services re-use was clear and the results were alarming.
When the numbers were presented and described to the business stake holders, there was a new appetite to implement a robust SOA Governance (Chapter 2, Implementation Use Case, describes this in more detail). It was clear that the first and most immediate priority was to resolve the issue of service visibility to substantially reduce the development costs. In addition, when the Architects analyzed the total cost of ownership of all the services through the maintenance, enhancement, and bug correction of duplicated functionality, the figures were even worse! It was important to act quickly as many projects were already in flight and if this problem was not solved quickly, the window of opportunity would be lost.
The first remedial step undertaken was to analyze the existing SOA Design-time Governance. The following diagram depicts a summary of the SOA Software Development Lifecycle (SDLC) followed by Weir & Bell Telecoms:
The top five problems identified with this approach after careful analysis were:
- When the Service Discovery and Cataloging activities took place in initial projects, the outcomes were captured in Excel documents. Although this approach started off being acceptable, it wasn't enforced rigorously enough by a governing body. As the number of projects increased and the time pressures ensued, the Excel document quickly became outdated and eventually was no longer in use.
- Since the Architect and/or Designer did not have full visibility of the available Assets, (as the Excel was outdated) new Services were routinely designed every time a new functionality was identified. This was despite the fact that existing services might already be available with similar capabilities.
- Generally, documentation was all over the place and not version controlled or stored in a content server. Invariably, it was not possible to deduce which version of a document was the latest one or which one actually corresponded to a particular version of a service.
- Access control to the documentation and source code was not controlled and it was not possible to audit accessibility or access restrictions. This imposed a huge security risk as external consultants (or even internal consultants) without the appropriate clearance had the potential to find and utilize Assets containing sensitive information.
- Asset dependency was also identified as a big issue. The impact of changing a service on its consumers was not clearly understood or visible. For this reason, when changes were required to existing services, rather than changing the service, a new version was created which would run in parallel to its older sibling. There was no service retirement policy in place, mainly because IT did not want to remove a service without understanding the impact of doing this. In short, services were never decommissioned.
- Poor quality data can also be an issue. Services did a great job in exposing data that was previously inaccessible; however, the quality of the data itself was questionable. Duplicates, inconsistencies, and irrelevances in data were some of the data issues identified.
Tip
The topic of data quality and issues that this caused Weir & Bell Telecoms are covered in greater detail in Chapter 11, Extending Design-time Governance with AIA Foundation Pack 11g.
To solve these problems, it was clear that the existing processes needed enhancement and governance. It was concluded that OER would be used as the single and centralized tool for:
- Architects and Designers to search existing Assets and their status.
- Architects and Designers to catalogue and prioritize candidate services.
- Designers and Developers to search and use existing Assets using their IDE.
- Designers and Developers to catalogue new built Assets using their IDE.
- Architects to classify all Assets depending on their type.
- Architects to specify architecture blueprints and other architectural relevant templates.
- Establishing the relationship between Assets, Asset types, and consumers.
- Managing Asset versions and their status.
All of the preceding should be possible despite the fact that projects might be running in parallel.
Furthermore, it was decided that all the document deliverables would be version controlled. For this reason, new additional requirements were identified as follows:
- All the document deliverables such as Use Cases, High Level Designs, Detail Designs, and Unit Test Plans, should be associated in OER to their relevant Assets.
- More rigorous Access Control Restrictions should be enforced so that it would be possible to restrict the visibility of sensitive information when necessary.
Based on the preceding requirements, an updated view of the process was created in which the individual and outdated Excel documents were superseded by the use of OER for the discovering and cataloguing services. In addition, OER would also be used by Designers and Developers to further discover and harvest services throughout the design and build stages of the lifecycle. The new process looked as follows:
These simple yet effective changes allowed Weir & Bell Telecoms to realize substantial cost savings through service re-use. Also, by allowing Architects, Designers, and Developers to discover and catalogue new services in OER, it was possible to identify opportunities for re-use earlier in the lifecycle.
Furthermore, because all the documentation was now version controlled in a content server, it was possible to harvest these as Assets into OER and then associate them with the relevant services. The following Asset Relationship View was modeled in OER:
Having a full relationship view of the Assets not only provided visibility of existing Assets but also, importantly, the relationship between the Assets. This proved to be invaluable, especially when it came to understanding the impact of change.
The following sections will deliver a comprehensive guide on how to perform an initial configuration of OER so that the requirements listed previously can be addressed by using the Harvester and Asset Lifecycle features of the product. The latter features will be covered in Chapter 5, Harvesting.