Enterprise business integration is a means to an end. Although an agile infrastructure enabled by integration can have substantial impact on the overall success of the business, technology alone has no value. Two companies can use the same technology and have very different results. For example, when General Motors focused on significantly reducing the time needed to design and engineer cars, it was able to achieve dramatic results that have given it a significant edge over the competition during the downturn in the economy. General Motors' focus on business objectives and improving processes in the context of available technology and an architecture were key to success. The technologies that enabled General Motors to do this were available to all of its competition, but were not applied to the same business initiative. It is therefore critical to tie integration initiatives to business needs as early in the process as possible to ensure success.
There are many approaches, methods, and tools that organizations apply to improve their processes. Six Sigma is one that has achieved a significant following. General Electric has turned Six Sigma into a corporate mantra. Other approaches include the use of balanced scorecards that focus staff on individual and group goals that relate to improving operations. ROI-based approaches calculate the ROI obtained from investing in a given improvement. The application of industry benchmarks is often used to set the goals for improving a process, and can be used in conjunction with balanced scorecards and ROI-based approaches. Many other approaches exist, including a variety of proprietary approaches applied by different consulting firms.
The success of strategic business initiatives depends upon the alignment of IT and business goals. However, without the underlying ability to execute these business strategies and initiatives, they will not yield the same competitive advantage. For example, in the late 1980s business process reengineering (BPR) was the consulting world's latest silver bullet. Many of the great ideas that resulted from a company's BPR efforts did not yield the anticipated results because they required systems to be reorganized and integrated in ways never envisioned when they were created. Radically reengineering core business systems was too disruptive and expensive to achieve an ROI, and many of the plans remained on paper. At the time, the technology was not mature enough to enable companies to leverage their existing systems and integrate them to support new business processes. Without the right technology, the ability to execute on a business strategy and related process improvement is not feasible. What makes Six Sigma and other approaches work is the availability of technology that allows for the integration and implementation of solutions that were not feasible in the past.
The most successful implementations are those that meet the business requirements and contribute to the overall success of the business. IT organizations that use business metrics reflecting key performance indicators (KPIs) have greater success than those that use IT metrics, such as system performance. Meeting business expectations requires correctly defining the drivers, intent, scope, and metrics that measure success. The Business Drivers and Requirements Specification is the document that defines all three. As such, it is used when creating the integration strategy (see Chapter 3) and making technology decisions that ensure alignment with business goals.
The most typical types of business initiatives driving integration requirements today include reducing business cycle times to increase efficiency and competitiveness, improving customer satisfaction, mergers and acquisitions, and regulatory compliance. Some of these initiatives are strategic and some tactical. Different business requirements call for different types of integration technologies.
Companies embarking on initiatives to improve business efficiency can have either a strategic or tactical focus. Strategic initiatives include moving to real-time business processes or integrating transactions across the value chain to reduce time and costs. A strategic approach to improving business efficiency requires integration to automate and manage business processes. Improving business efficiency is an ongoing process, not a finite implementation project. Process simulation provides the ability to analyze process flows as optimized for cost or time. Although still a premium feature among vendors, it will surely become a necessity because those companies that use the technology will gain clear competitive advantage.
Tactical initiatives to improve business efficiency include eliminating reconciliation issues, data inconsistency, and reporting discrepancies across the enterprise. Tactical initiatives typically take less time, consume fewer resources, and cost less than an enterprise solution. The technology necessary to implement tactical solutions is typically only a portion of the full integration platform. However, to avoid having to integrate the integration technologies, even tactical solutions should be considered in light of strategic initiatives so a flexible architecture can be developed and maintained. General Motors has turned this strategy into a science in its organization, creating remarkable business results (Alice Dragoon 1998; Moozakis 2001). This is described in Case Study 2.1.
Companies embarking upon projects to improve customer satisfaction may be considering a number of different technical solutions, including Customer Relationship Management (CRM) systems, portals, mobile integration, sales force automation, or a combination of all or some of these. Again, some of these projects may be enterprise-wide and strategic to the organization, and some may be more tactical in nature.
Customer satisfaction can be measured by
Customer retention statistics
Response time to customers
Number of complaints
Issue resolution rate (% and time)
Error rates
Customer value (computed as sales per customer or lifetime value of customer)
Because of the need to track and analyze customer satisfaction, process management simulation and analytics are key technologies for strategic initiatives. Tactical solutions typically focus on a particular technology, such as portals or mobile technology, and may also require a combination of technologies. The key is to enable individual technologies to be deployed at the lowest cost and least amount of time possible, and integrate easily with other integration solutions whenever necessary. Companies need to at least have an enterprise road map to enable the infrastructure to be deployed tactically and work on an enterprise strategic level as well. Government organizations are often driven to improve the service to the citizen. There is enormous pent-up demand for these types of initiatives. Oftentimes a modest investment can have extraordinary results as seen in Case Study 2.2 on the work done by Sacramento County (http://www.softwareagusa.com/media/case_studies/pdfs/Sacremento_CR.pdf).
Mergers and acquisitions inevitably result in redundant and incompatible systems, leaving companies with just a few choices:
Choosing one system over the other and a large data conversion project
Leaving the systems in place and integrating them
Implementing an entirely new system, then converting or integrating both
A combination of approaches may also be used. Integration projects resulting from a merger or acquisition are usually treated as tactical projects or one-time conversions. However, companies seeking to improve business efficiency through the merger and acquisition should also consider business processes integration and management across all business units, regardless of where they are located or the technology the systems use. This undoubtedly will require a higher initial investment, but it also offers the highest potential ROI.
A number of regulatory requirements, including the Sarbanes-Oxley Act, Health Insurance Portability and Accountability Act (HIPAA) in the healthcare industry, and T+1 trade settlements in financial services, can be best be accomplished through enterprise integration. In some cases, regulatory or industry compliance is being defined in such a way that they are at the heart of technology integration. Case Study 2.3 discusses the trend toward the definition of XML-based standards for achieving this compliance.
Sarbanes-Oxley requires auditors to not only certify the numbers, but also the process used to derive the numbers. For example, revenue recognition across a company is an important process that must be certified. Companies can document the process, then manage it after the fact, using end-of-month or quarter reports to fix problems long after they have occurred, or they can implement business-process integration to automate, monitor, and manage critical business processes in real-time.
In addition to all those brochures about patient confidentiality and privacy that you have received from your doctor, pharmacist, and other healthcare providers, HIPAA requires and specifies electronic transactions between payers and providers. Companies needing to be HIPAA compliant are implementing integration technology to accept XML transactions and integrate them with their back-end systems.
The finance industry has been moving towards reducing the amount of time it takes to settle a trade to one day. Although regulatory compliance has been extended until 2005, many financial institutions are moving forward on the initiative now. Long settlement cycles make risk management much more difficult for portfolio managers, and causes reporting discrepancies requiring extensive reconciliation procedures. Therefore, straight-through processing has become a watchword in the financial services industry. The goal is to automate the settlement of the trade across multiple systems, platforms, languages, and technologies. Financial services companies were early adopters of integration technology. As the financial services industry slowly moves towards requiring compliance with the T+1 standard, integration is becoming a requirement. When companies implement solutions to meet these requirements, they will also want to ensure the infrastructure is adaptable to also meet future requirements.
Taking the time to understand and document the business requirements is essential to ensuring the alignment of IT with the business strategy and it makes the project plan easier to sell internally. Failure to accurately define business requirements can lead to wrong decisions and failed implementations. When defining enterprise integration requirements, you need to answer the question, “What is the business problem we are trying to solve?” so that the technical implementation can best meet the business needs. The most critical element of this stage is the identification of the business champion for any strategy or initiative. Empirical evidence suggests that without this champion, the chance of a successful implementation with meaningful impact is substantially reduced.
The requirements process involves the business champion, management and staff involved with the process being addressed, and IT project managers. Projects with enterprise scope may include multiple lines of business in the company. However, even when defining projects with more limited scope, it is helpful to identify related initiatives that could impact architecture or technology decisions.
When defining requirements, it is also important to take the time to understand how the business operates and the impact new business processes will have. Identifying the business benefits of the initiative is an important part of the process; down the road it will help justify technology investments as well as explain the necessity and benefits of change. Therefore, take the time to define the impact and benefits to all parts of the business and all employees who will be affected by the new implementation.
The business requirements will determine whether the initiative is strategic or tactical in nature. As described above, the process, technology, and approach can differ for strategic and tactical projects.
Achieving the right balance of documentation is often the most difficult part of any project. Too much documentation often wastes time, is not read by the stakeholders, or is poorly maintained as the project naturally evolves. Poor documentation leads to confusion in later stages. Our philosophy is to provide a minimalist approach to documentation. We will focus on the required elements and the process that leads to the creation of the document. These can be tailored to the needs of the organization.
The Business Drivers and Requirements Specification is the document that describes what the business is attempting to achieve. This specification becomes the guiding light of the project and will be used until the system is operational to assess the business impact. When the development team is provided this level of information, it helps them stay focused on the goals leading to a higher probability of success in the development phase. To see the full Business Drivers and Requirements Specification, please see Appendix A. Note that the brackets in the tables refer to specific information to be added to the table.
The introduction should be a short executive overview of the specification. In addition, any special aspects of the project should be addressed, including the sponsoring organizations and business champion. A history of the initiative would be helpful as well. At the end of this section the reader should have an understanding of who, what, why, and how the business initiative and strategy evolved.
This section defines the scope of the Business Drivers and Requirements Specification, specifically whether it is enterprise wide, or for a specific business unit or business initiative.
All stakeholders in the requirements process should be identified, including business managers, the sponsoring organizations and business champions, and owner of the proposed initiative. The artifacts created in this process will be used by enterprise architects and developers to ensure technology solutions are aligned with business requirements.
The statement of purpose is a succinct section used to communicate the business goals and functions of the initiative. It makes the business case for the initiative. It does not include implementation of the technology. One of the more important aspects to address is the impact to the organization once the initiative is complete. Large initiatives will have a major impact that will transcend the technology and affect how people work. Many projects have failed because the corporate culture was not ready for the change.
The business drivers should be a simple and clean statement of the problem. For example, bring cars to market quicker and more cost effectively than before. This section should only have one or two items. Each item should be classified according to the categories we discussed at the beginning of this chapter. If there are too many drivers then the initiative should be reconsidered. Is more than one initiative being addressed?
The business strategy should align with key strategic business initiatives, such as improving business efficiency through process improvement. The functional scope should define the business processes included in the initiative.
The business goals are used to measure and assess the achievement of the business initiative. Examples are reducing design and engineering time from 48 months to 18 months or reducing costs by 20%. These goals need to be realistic to be believed by the business stakeholders as well as the IT organization. This section should outline the benefits to the organization in both subjective and objective terms of achieving the goals. Each of the goals and benefits can then have a value attached to them, whether they are financial, a competitive differentiator, or focused on customer satisfaction. This section makes the business case for the initiative. An extremely useful element of this section is a description or use case of how things will be different as a result of the initiative.
A statement of purpose should be completed for each proposed business initiative. Figure 2-1 (page 30) is an example Statement of Purpose.
With the approach in hand, this section of the specification should list high-level costs and an estimated time frame. Costs at this point should be a rough order of magnitude and used for budgeting purposes and estimating ROI. It must be understood that these will be refined in the follow-on phase with the next level of detail. Figure 2-2 (page 31) is an example cost estimate.
This section documents the potential or expected ROI for the business initiative under consideration. Although cost estimates are still at the ballpark stage, it is critical to do an ROI analysis based upon the benefits, cost, and organizational impact.
You can use the template shown in Figure 2-3 (page 32) to guide your assessment of an ROI for any initiative. If the ROI is low, it may be necessary to get a better handle on the costs and the organization might only give a provisional approval to proceed until costs and impacts can be refined.
The metrics for success refine the business goals into measurable key performance indicators (KPIs). In some cases, the business goals may be of sufficient detail to translate directly into KPIs. Metrics should be defined by business goals. For each goal there can be more than one metric. In addition to the value of the metric, it should include details on how to collect, frequency of collection, and owner, as shown in Figure 2-4 (page 33).
A risk analysis should be conducted that defines the known areas where there are significant lack of detailed information; difficult issues such as organizational, cultural, technical, or management challenges; and ability to achieve the desired business result.
The risks are a collection of everything that can or may go wrong. The risk analysis may also include a list of assumptions that may be wrong or need further information to be validated. Each risk should be associated with a plan to mitigate the risk and the owner of the risk. Figure 2-5 (page 33) is an example of a risk analysis table.
This section should provide any final comments on requirements. It should include any known constraints or other business factors that could affect architecture, design, and implementation.
The Business Drivers and Requirements Specification becomes the guiding light of the project. When the development team is provided this level of information, it helps them to stay focused on the goals, leading to a higher probability of success in the development phase.
Ensure that all enterprise integration efforts are closely aligned with business goals and objectives
Involve IT in strategic business planning
Appoint business project managers for all IT projects
Create business metrics to measure success of IT projects
Revisit business goals and objectives throughout the integration life cycle
At this juncture the process can differ for strategic and tactical projects, as shown in Figure 2-6. You must define the integration strategy and technology to use on the tactical projects, but it is far better if the recommendation comes from the Enterprise Integration Strategy and Architecture Plan. This ensures that the solution fits into the overall infrastructure and enables agility and reuse on follow-on projects. Having an Enterprise Strategy and Architecture Plan in place is critical to having a long-term supportable environment.
It is especially important to understand how a tactical solution fits into the overall enterprise architecture. For example, enterprises looking to maximize agility and implement real-time processes may view each tactical implementation as a building block in the overall architecture. Rather than take the fastest and most economical path to integration, they may decide to invest in creating reusable business services. Even if the implementation has little bearing on the overall enterprise architecture, it is still important to ensure that enterprise standards are met.
The next step is to create or review the Enterprise Integration Strategy (see Chapter 3).