Software project management has been the bane of CIOs for years. The intricacies of designing, developing, implementing, and maintaining software systems are continuing to increase, while the required time to market, and the patience of consumers, have consistently decreased.
Most CIOs are familiar with The Standish Group’s “Chaos ‘98” study, which reported that 75 percent of all software projects fail because they go over budget, miss the delivery dates, or are of substandard quality. The report found that the failure rate rose to 100 percent for projects over $10 million.
In the report, Standish proposed several management conditions that would improve the likelihood of success. I believe, however, that it will take more than the resolve of management to do better. In fact, I think today’s CIO needs to step up and mandate standards and infrastructure that will reduce the amount of development required for additional business functionality. To do this, you'll need to implement a standard business framework and architectural template.
In this article, I'll talk about what makes up a standard business framework and how you can build one around which to structure your organization's systems.
What is a standard business framework?
One thing we can learn from the Internet experience is that building a standard platform encourages integration and innovation. I believe CIOs need to begin looking at their organizations as "mini-Internets" that serve applications across a core TCP/IP platform.
You should begin to think of yourself as the service provider for your organization. But networking interoperability is only the beginning. The next-generation provider needs to be able to provide the same level of interoperability between applications that the Internet provides for devices.
In order to achieve this application interoperability, CIOs will have to force standards for application development and external access to those applications’ business processes and underlying data.
Why standards are necessary
Most companies fail at establishing a standard business framework because they attempt to adopt a single development platform or set of development technologies, only to discover that their customers (departments or business units) either have special needs that can’t be met by that platform or have existing systems that they cannot afford to rewrite in order to become standard.
The secret most of us have missed involves the option to standardize on interface technology but not necessarily on a single development platform. To be fair, the ability to do this has just cropped up, and most vendors are marketing it the wrong way.
Companies like Microsoft, Sun, IBM, and Oracle are pushing their Web services initiatives as "the path" for business process integration across the Internet, but I think the forward-looking CIO will look at the technology and consider their departments as "companies" and their data center as the "Internet" that ties those companies together.
Taking this position allows the CIO to build his or her internal infrastructure to support interoperability standards like XML and SOAP without having to dictate that departments (or the contractors and consultants they employ) use any particular language or toolset. It’s the CIO’s responsibility to make sure the data center provides the Web services fabric to which various applications can be sewn. Once the technical infrastructure is defined and implemented, the next step is to consolidate the definition, operation, and exposition of common business services on top of the Web services fabric.
Building a standard business framework
So let’s assume we all agree that building applications that support open interfaces makes as much sense inside the firewall as it does outside. What’s next? I propose that CIOs lead their organizations to embark on a three-phase business framework development plan.
Phase 1: Determine if key processes can be connected using a common interface set
The first phase involves identifying all of the key business processes in the organization and their technical readiness to be wrapped by a common set of interfaces.
For example, does your accounting system allow sufficient programmatic access to key data elements (customers, invoices, purchase orders, etc.) to allow other systems to deal with the elements as complete objects through a common business interface? Were key operational or departmental systems built on an architecture that can easily be extended to support external access via a standard interface mechanism?
Phase 2: Understand system/process relationships so you can build logical interfaces
The second step is building a conceptual model of the systems and processes in your organization and the relationships between them. From this model, you can create a logical set of interfaces for each system that lets them talk to each other in simple, understood relationships.
The goal is not to replace the functionality of these systems but to build interfaces that allow them to interoperate at a higher level. Most of these systems already interoperate at the data level—i.e., you have developed ways to pass data between your operational systems (like shop floor manufacturing or time card entry)—and accounting systems. But this data movement is performed on a field level by some kind of data pump rather than at the interface stage at a process or object level.
Phase 3: Build system wrappers and interface code
The third step requires building both the wrappers for the individual systems and the business interface code to let them communicate. Wrapping systems with SOAP layers allows you to do two things simultaneously: recoup the investment made in existing systems and make that resident data available to the organization.
You could argue that building the wrappers makes you more dependent on the legacy system and therefore makes upgrading more difficult. But I disagree. If you define a solid set of interfaces that define how your company does business and then enforce those business processes on the underlying systems using these wrappers, then the underlying system ultimately becomes a commodity and is therefore easier to replace. Once interfaces to your systems are in place, you can build software that uniquely defines your business processes but uses existing software to implement them.
The real magic in this approach is that, once completed, the departmental systems built on this framework can automatically interoperate with other companies who have implemented their own Web services interfaces. The departmental systems have, in essence, been built from the ground up to consume other systems’ data and to expose their own using SOAP interfaces.
Next week, we’ll look at using standard architecture templates to enforce the use of your business framework, and I'll walk you through a real-world scenario that demonstrates the framework development process.
Are you using a standard business framework?
Tell us how you went about it and how it has worked out.