SOA demands a new 80-20 rule for application development

SOA demands a new 80-20 rule for application development

Summary: 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.


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.

Topics: Apps, Software Development

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Application development has greater priorities than SOA

    There is no dispute SOA will make life easier in the future to connect and reuse suitable services many of which may be external. However to put future application development dependent upon SOA misses the point about addressing just what the future build of applications will require. The first most important requirement is to eliminate the gap between business and IT with a close second to bring the end user i.e.people into the driver seat from their perspective. This is the spot where competitive advantage is relevant ? it is also the point where the greatest risk lies in major breaches of compliance. The investment in back office has been made - if it isn?t broken don?t fix it.
    The opportunity now with connectivity anywhere at any place lies in focusing on the human interaction element making sure the right information is delivered to the right person at the right time to do enable the required tasks to be completed. This requires a dynamically created user interface that has at core resources (people or machines), roles, task and data. A process is only a series of tasks and thus we have a simple new approach that will allow creation of custom applications without having to programme specific business functionality ? just put the tasks in the required order incorporating the required rules. This can be in a self-contained function independent environment where business can now specify exactly what they require and be guaranteed it is delivered bug free as the code never changes. Research has established there are less than 15 task types that can address any business eventuality - the ultimate flexible custom packaged application - nothing to do with IT architectures.
    Got it yet? Now you see why SOA is only a nice to have - unless of course you are a supplier!
    David Chassels
    • 15 tasks

      David, that comment was helpful, thanks. What are the fifteen types, or where do I find that list and others like it?

      -----less than 15 task types that can address any business eventuality-------
      • "Tasks drive any business "

        A task is an action that is performed as part of a process. A task may be performed by a user or it may be a system task that dos not require user interaction.
        A normal task is a user task that may be used to inform a user that a task needs to be performed and to allow the user to mark the task as completed.
        A form task is a user task that displays a form for information or for a user to complete.
        A calculation task is a system task that performs a calculation to manipulate data as required
        A program task is a user task that may be used to start an application for the user, such as a word processing application.
        A pending task is a user task that may be used to suspend a process until an event task or a user indicates a particular event has taken place by marking the pending task as complete.
        A sub-process task is a system task that may be used to start a run of another process. The new process becomes a sub-process in the current run of the parent process that calls it.
        An event task is a system task that may be used to mark one or more outstanding pending tasks in other processes as complete.
        A report task is a user task that opens the report application and displays the results of a predefined report to the user or where required
        An import/export task is a user task that either copies specified data from a text file into a database or copies specified data from a database into a text file.
        A web report task is the form the users see via a browser. It replaces the form task for internet, intranet or extranet applications. .
        A server side message queue task is a system task that runs a specified server Java script on the Procession server.
        A finish task is a system task that must be used to indicate the end of the process.
        Links connect each task, can be used to set up rules and can have multiple multi-branching and asynchronous capability of the business process with both tributaries and distributaries to/from the tasks.

        From this business knowledge now drives applications built via a graphical designer - no notation language (BPEL or BPMN) or compiling and all in a data centric environment.
        As for others not many - too wrapped up in "technology" - business is too simple and boring! - But Microsoft look like they are moving this way but 10 years behind or maybe this thinking was 10 years too early......?
        David Chassels
        • Thank you!

          Thanks. That's helpful. I write small Access applications and sometimes it's difficult to get started analyzing their needs.
  • application developers

    We can provide a full range of social networking applications strategy, design, development and marketing for your business. Our service offerings will allow you to maximize and leverage the social networking social graph of 200+ Million users.
    Are you in need of a custom Facebook application or an OpenSocial application for social network? We are happy to build even the most robust applications to help promote your company in the realm of social media across any social network.
  • Facebookster

    Facebookster - We can provide a full range of facebook application strategy, design, development and marketing for your business. Facebookster
    Visit now:
  • bebo

    Bebo Developers is the name of a dynamic quality assertive and low cost team of developers who expertise in developing Face book, Open Social applications that include Bebo, LinedIn and iGoogle widgets.
    Possessing some of the best available talent present we are proud to have developed a
    Wide range of deployed applications that rank amongst the highest used by everyday Face book and Open Social applications. The increasing popularity of Face book
    Applications has made every businessman want to get his hands on a Face book application that increases his market and product and this is where Bebo Develop.
    Visit now:"</a>