Sunday, July 8, 2007

SOA demands a new 80-20 rule for application development

Services oriented architectures (SOAs) are not only forcing a new way of looking at how to construct applications and composite services -- SOA is now changing the meaning of what custom applications are and how they will be acquired. And this change has significant ramifications for IT developers, architects and operators as they seek a new balance between "packaged" and "custom" applications.

As more applications are broken down into modular component services, and as more services are newly created specifically for use and reuse in composited business services, the old 80-20 rule needs to make way for a new 80-20 rule.

The old 80-20 rule for development (and there are variations) holds that 80 percent of the time and effort of engineering an application goes into the 20 percent requiring the most customization. Perhaps that's why we have the 90-10 rule, too, which hold that 90 percent of the execution time of a computer program is spent executing 10 percent of the code!

SOA skews the formula by making more elements of an application's stated requirements readily available as a service. As those services are acquired from many sources, including more specialized ones (from third-party developers or vendors), a funny thing happens.

At first the amount of needed customization is high -- maybe 80 percent (a perversion of the old rule) -- either because there are not many services available, or because the services are too general and not specific to a specialized vertical industry or niche function.

Then, over time, with investment, the balance shifts toward the 50-50 point, and reuse forms a majority of a composite applications or business process, even for highly specialized applications. These composited functions then become business-focused service frameworks, to then be reused and adjusted. Those architects that gain experience within business niches and verticals to create such frameworks can make significant reuse of the services.

They, and their employers, enjoy tipping points where the majority of their development comes from existing services. The higher they can drive the percentage of reuse, the more scale and productivity they gain. They become the go-to organization for cost-efficient applications in a specific industry, or for specialized business processes.

These organizations benefit from the new 80-20 rule of SOA: The last 20 percent of customization soon takes only 50 percent of the total time to value. The difference from 80 percent is huge in terms of who does SOA best for specialized business processes. And it makes the decision all the more difficult over how to best exploit SOA: internally, or via third parties, integrators, or vendors.

It used to be that the large packaged applications vendors, like SAP, Oracle and Microsoft, used similar logic to make their vast suites of applications must-haves for enterprises. They exploited reusable objects and components to create commodity-level business functional suites that were soon deemed best bought and loaded, and not made, company by company, across the globe.

But with SOA the same efficiencies of scale and reuse can be brought to much more specific and customized applications. And those applications, if implemented as web services, can be ripped up, shifted, mashed adjusted and changed rapidly, if you know enough about them. The flexible orchestration of loosely coupled services means that development teams can better meet business’s changing needs.

A big question for me is which development teams will be benefiting most from the new 80-20 rule SOA activities? After attending the recent IBM Innovate conference in May, it's clear that specialization in SOA-related business processes via services frameworks will change the nature of custom application development. IBM and its services divisions are banking that the emerging middle ground between packaged applications and good-old customization opens up a new category they and their partners can quickly dominate with such offerings as WebSphere Business Services Fabric.

If IT departments inside of enterprises and their developer corps can not produce such flexible, efficient services-driven business processes, their business executives will evaluate alternatives as they seek agility. Such a market, in essence, forces a race to SOA proficiency and economy. That race is now getting under way, pitting traditional application providers, internal custom developers, vertical application packagers, and systems integrators against one another.

Even as businesses examine services-oriented efficiency and SOA benefits, they will also need to consider who owns the innovation that comes when you develop a service framework that enables a vertical business process. It would be clearly dangerous for any company to outsource its process innovation, and to lose intellectual property control over their core differentiating processes, either to a consulting firm that would develop the customizations, or to a software vendor that would productize it as a framework.

Executives will need to balance the enticements of outside organizations with a powerful SOA arsenal against the need to innovate in private, and to keep those innovations inside. They must be able to use what's available on an acquired basis to compete -- and which benefits from a common structural approach of highly granular reuse -- but not so much that they lose their unique competitive advantage.

And this brings us back to the new 80-20 rule for SOA, which also holds that companies need to retain 80 percent control over the 20 percent of the business processes that make it most competitive in its own markets. The move to a services environment via outside parties alone risks violating this rule. Therefore, internal IT must advance in SOA proficiencies as well, if only to be able to keep up with the third parties that will be servicing the competition.

We really have entered a race to SOA benefits and efficiencies. Time to lace up your running shoes once again.

No comments:

Post a Comment