Ambitious as the title may sound, there is a basic truth to the fact that the principles of SOA reach far beyond software development, pervading virtually any business process and practice.
SOA is often mistaken as something unique to the craft of software development. But, look around: SOA is fundamental to a broad range of disciplines. Look closely at any domain—from financial services to the manufacture of the sort of products you can drop on your foot—and you'll see shades of service orientation.
Virtually any product today is a re-composition of reusable components. Financial services firms reshuffle products to create mass-customized offerings tailored to specific customer profiles. Manufacturers recompose components to create new products. Likewise, drug makers create new products based on a reassembly of the same stuff—new combinations of the same base ingredients often yields a whole new product. Sound familiar? Companies do this to reduce costs and to create new revenue streams based on line extensions—it's about return on assets (ROA), which is a fancy way of saying reuse.
There are a few fundamental design principles that inform a service-orientated approach—whether you're talking about app dev, automobile production or anything in between.
Designed for reuse
Service design requires a keen appreciation for patterns. The key is that not everything is meant to be reused. Reusability comes from common requirements, which are driven by a top-down interrogation of core business functions. This reveals the patterns that define reusable components. This idea is widely understood in practices outside of application development, where reusability always comes from a top-down perspective. But a common trap in our version of SOA is to create a dependency on community contribution of services—from the bottom-up. Services need to be defined and designed with reuse in mind—they must apply and appeal to an audience of many. Creating a marketplace for service contribution seems like the right idea, but more often than not, the services that are contributed are not truly designed for reuse. The result is a vast catalog of services that typically doesn't satisfy consumer needs. The bottom-up approach only works if you have a formalized review and approval process as part of your governance model that systematically separates the wheat from the chaff. Take a page from the "other" book of SOA: Just because it can be reused, doesn't mean it should be reused!
Use of standards
Reuse requires compatibility—and compatibility requires strict adherence to standards. Whether you're talking about SOA-based business services or the components that comprise a finished automobile, standards are fundamental to scalable reuse. In the absence of standards, we need multiple versions of a component to fulfill the same function. This is the classic definition of inefficiency! It creates a massive cost drag and resource burden around the creation and maintenance of these components—and the burden grows exponentially with scale.
Composition vs. creation
Gone are the days of doing things the hard way, for the first time every time. SOA-based approaches have replaced yesterday's notion of creation with today's notion of composition. Building things used to be complex and specialized. Now they're simple and generalized. In all domains that draw on the principles of SOA, the design center has moved from detail to abstraction, from content to context. Reusable components based on the use of standards make it easy to scale processes, draw on less specialized skill sets and mix the virtues of customization and scale.
Dealing with Darwin
One interesting SOA trend that has emerged outside of the traditional application development domain is the service orientation of content—transforming monolithic documents into topic-oriented chunks that can be composed to create new documents and deliverables. DITA—or Darwin Information Typing Architecture—was conceived as a model for improving the reuse of content assets by turning them into well defined topic-oriented components. So, rather than creating content net-new or copying and pasting what may or may not be the most current and authoritative information, organizations manage a repository of DITA topics that can be centrally managed, maintained and reused across the enterprise. Organizations can even leverage taxonomy, ontology and search technologies to semantically match content with the appropriate business scenario. For example, a service incident from a customer is automatically matched with the appropriate response, which is authored and managed as a DITA topic.
By the way, DITA gurus Michael Priestley and Amber Swope recently published the DITA Maturity Model, which provides a framework for understanding how to adopt DITA as an approach for content reuse. It's an interesting context for understanding how to make DITA part of your content management strategy. You can download the DITA Maturity Model here: http://na.justsystems.com/files/Whitepaper-DITA_MM.pdf.
About the author
Jake Sorofman is Senior Vice President of Marketing and Business Development for JustSystems, the largest ISV in Japan, and a leader and innovator in XML and information management technologies. Learn more about JustSystems at www.justsystems.com and contact Jake at jake.sorofman@justsystems.com.
