The Shift to Service Orientation
Is your team ready to look beyond object-oriented techniques?
Service orientation is all about reuse and agility in the enterprise. We as technologists have evolved the reuse story for quite some time now; first with methods within our code, then with reusable deployable components and now with services.
But object-oriented design principles like encapsulation, polymorphism and inheritance have served us well, making our code constructs reflect how we think of real-world concepts. These techniques make communicating and thinking about code and software development easier, especially between developers and business experts.
A major challenge as development teams move toward service orientation is the impedance mismatch between the concepts inherent in object-orientation and the goals of service-orientation. The tooling also needs to catch up, although Visual Studio and .NET Framework, notably Windows Communication Foundation, support service-oriented design quite well.
Consider an enterprise that sells products to retail customers. The business view of a customer includes many things. For example, a customer may have zero or more invoices, orders, contracts, agents and locations in their environment. This can easily be modeled in any object-oriented language because the code permits the developer to navigate the object structures, moving from a Customer object to OrderLineItem objects -- within contracts -- or PurchaseOrder objects, as a reflection of the relationships in the real world.
When viewing the same relationships from the enterprise business perspective, a different picture emerges. Often different groups within the business handle various aspects of working with a customer. There's a good chance that the people who deal with customer contracts may not be the same people that manage the invoices or the purchase orders. Another likely scenario is that several groups interact with the same data; the accounting department will need to know about orders that are placed, as will the shipping department. However, each group views the information differently. Keeping the business perspective is increasingly important with service orientation.
When designing a service to support purchase orders, it's very possible that the order information will need to be managed in line-of-business (LOB) apps that support different aspects of the business. This is the expected situation in most, if not all, enterprise organizations. Similar situations will arise for other key entities such as customers and invoices.
The challenges that a service-oriented architecture (SOA) is meant to address are much more focused on the individual entities than on the relationships maintained between the entities. Services that support purchase orders should not know everything there is to know about the customer; the key data that can be used to uniquely identify the customer is enough. This enables an Orders service to utilize the Customer service, if it needs to, in a loosely coupled manner. This loose coupling is what enables the agility and reuse that a SOA promises.
A New Way
What all of this means is that the code we write in our LOB apps -- which are meant to embrace a SOA -- needs to break from the full benefits of object orientation. As is often the case, we'll find the need to build apps that interact with more than one of the entities in question. A shipping app may need to know about customers, their orders and perhaps shipping agreements that are contained in contracts. Rather than storing and manipulating all of the relevant entities within a single app, we may need to accept an order and use the customer identifier to make a call to customer service to retrieve the customer information that the shipping app requires.
The benefits are worth it. Despite seeming like we're moving backward, this actually enables more robust and agile enterprise systems. If the shipping system is required to call a Customer service rather than simply navigating the PurchaseOrder object to the associated Customer object, we have the ability to change the system that manages customers without needing to alter the application. We can also gain the benefit of moving duplicated customer data from several systems into a single, master customer-data store.
Naturally, caution must be exercised to ensure that performance requirements are still maintained. As data is moved from being stored in multiple systems to a single, master data system, the performance of any single application may be at risk as more applications are accessed to support a single business process. Management of the services must also be carefully considered. Proper governance at the enterprise level needs to be in place as multiple consumers of a single service start to materialize. This is a process shift from building LOB apps in silos.
So go forth and service-orientate, but be aware that it requires a shift in perspective and approach compared to building object-oriented, self-contained LOB apps.
Larry Guger is director of Microsoft practice for Online Business Systems.