Appendix A. Case Study Conclusion
The case study examples provided throughout the preceding chapters demonstrated the application of service-orientation design principles with Java services and technologies in a diverse variety of scenarios. This appendix summarizes and concludes the storylines of the two organizations originally established in Chapter 2.
A.1 NovoBank
NovoBank has successfully completed the first roll-out of their next-generation banking system. The SOA architects at NovoBank were able to achieve the three main objectives of their transformation program as follows:
• Improve Time-to-Market – NovoBank was able to build a layer of business, utility, task, and entity services to help decouple their channel applications from the core legacy banking systems. With the availability of a reusable set of business services, enhancing existing channel applications is much easier than before. None of the channels are tightly coupled with any of the core systems. NovoBank was able to optimize their business processes and drive greater automation through the use of new orchestration services composed of different business, utility, and task services. The availability of different services affords the IT staff the ability to compose in different contexts in different business processes.
• Reduce Operational Costs – The technical costs of ongoing application maintenance or system integration efforts have been reduced by 20%. The bulk of cost savings were realized by leveraging the new services and avoiding one-off, custom developments in channel applications. However, the original target of 30% cost reduction in the IT maintenance budget was not met as some of the up-front costs of building out an SOA landscape and introducing SOA infrastructure solutions, such as ESBs, partially offset the cost reductions seen in routine maintenance efforts. However, it is expected that an economy of scale can be achieved with the services as more applications within other divisions in the bank begin using those services to avoid ground-up custom development.
However, along the way, NovoBank encountered the following challenges:
• Emergence of Mobile Computing – The proliferation of mobile devices, such as smartphones and tablets, made it imperative for NovoBank to introduce online banking applications. However, building applications to consume SOAP-based Web services was complicated. NovoBank IT staff realized they must build, at least in the short-to-medium term, REST API wrappers over their existing Web services that can be easily consumed by mobile applications. The architecture team is evaluating popular API management platforms to manage expansion in the mobile computing domain.
• Complexity of the Industry Standard Models – NovoBank standardized their canonical schema models on industrial financial messaging standards, but the complexity of the financial message schemas resulted in significant overheads during message parsing in their Web service implementations. In the end, NovoBank simplified the schema models to avoid unacceptable implementation and performance overheads.
A.2 SmartCredit Co.
SmartCredit was successful in building a set of REST Web APIs allowing retail chain stores to submit credit card applications on behalf of their customers. Store clerks can submit the applications from different mobile devices using the mobile applications built for SmartCredit by a third-party contractor. The simplicity of the REST APIs and the ubiquity of the HTTP communications protocol and data formats (mostly JSON, some XML) have helped the mobile credit card application scale well. The widespread in-store usage has also led to an increase in business volume for the retail stores. The successful adoption of the applications and resulting business has been noticed by a competitive retail chain, which is in negotiations with SmartCredit to enter into a similar partnership.
Technical implementation considerations aside, the SmartCredit IT team followed the service design principles outlined in this book to ensure services are built modular, reusable, and lightweight to offer immediate value to a wide variety of service consumers. SmartCredit spent a significant amount of time building the REST service contracts by focusing on identifying the resources, the associated representations, the corresponding media-types, and the appropriate, semantically correct application of uniform interface HTTP operations on those resources. Even though the JAX-RS APIs proved to be an efficient tool to build REST APIs, the top-down design approach supported by SmartCredit was effective in the adoption of the APIs.
As with any other complex IT initiative, the implementation was not without challenges. SmartCredit made a conscious up-front decision not to make use of any custom media types, as they were initially skeptical of introducing additional coupling through non-standard media types. However, the impending partnership with another retail chain and the need to accommodate slightly different forms of credit applications with different resource schemas resulted in the need to introduce custom media types. Rather than using the generic application/json or application/xml media type, SmartCredit is looking at using the following custom types:
• application/vnd.com.smartcredit.creditapp+json
• application/vnd.com.smartcredit.creditapp+xml
The custom media types will be able to communicate semantics about the resources in question and will help better enforce the service contract. SmartCredit will follow this approach for their next round of implementation.