GISdevelopment.net ---> GITA 2001 ---> Tying it all together

What is a business solution architecture?

Brian E. Willemsen
ComEd, Unicom Corporate Offices, 9th Floor
227 West Monroe St, Chicago, IL 60606

Rodney K. Dell
Convergent Group, 6399 South Fiddler's Green Circle
Suite 600, Englewood, CO 80111


Introduction
The creation of a strategically aligned business transformation program is difficult in the complex business and technology environment of today's utilities. This activity needs to have a sound and clear methodology that successfully steers an organization through the many confusing and conflicting forces.

Development of an end-to-end business solution mandates utilization of methodology that does not focus on departmental solutions or system (product) implementation. It needs to have a user-centric focus on implementing a manageable number of complementary technologies that support appropriate segments of the various key end-to-end business processes. These key business processes need to focus on adding value to the customers and incorporate an eBusiness strategy to expose required processes and information to customers and business partners. This information needs to come from the effective planned operational systems.

The development of a BSA provides the vehicle to coordinate and direct the many program role players and activities. The BSA defines the process, data, and system business owners so that stakeholder management and buy-in is managed throughout the project lifecycle. It is valuable for expectation setting at all levels of the organization and needs to be developed, refined, and approved by the various program role players and by executive management. The BSA provides consistent and mandated direction and scope for the business transformation program.

A key BSA function is the determination of the appropriate business releases along the time line to move the company to the agreed vision. The BSA is developed and iteratively refined, as the business releases move through their detailed design phase of development to fine-tune the program direction and ensure that learning from each release is captured for future releases.

Business Transformation Methodology
A business transformation program needs to have a methodology that enables a business to conceptualize the important perspectives and understand their interdependencies.

The recommended business transformation process used to develop the BSA is depicted in Figure 1 below. Figure 1 shows that the business process objectives and architecture, enabled by available IS/IT technologies, precede the selection of specific systems and the subsequent business release detailed design. The first step is to define the high-level business process framework, independent of the specific technology systems to be implemented, from which the high-level business requirements and integration requirements can be identified, to enable the strategic objectives to be achieved. These should then be used with the overall system architecture direction in the system selection process.

Figure 1: Business Solution Architecture Approach

The program needs to develop a conceptual design and document this in a BSA. Some of the major components of a BSA are defined below:
  • Strategic and energetic business leadership with clearly articulated mission, vision, and values
  • Executive management commitment in word and action to the business imperative and objectives for the radical business transformation change program
  • The organization's change management principles
  • Realistic business case cost and benefit tracking metrics
  • Appropriate strategic and tactical management metrics to document effective management of the business processes, system usage, data maintenance quality, and achievement of the objectives
  • An appropriate set of time-phased integrated business releases
  • A conceptual design of vision Business Process Architecture and the enabling System Architecture indicating the scope of the various business releases
  • Appropriate mapping of process to system and associated data ownership and the resulting functionality gap requirements and integration requirements
  • Appropriate executive accountability for the processes, systems, data and performance metrics
  • The agreed business rules and program decisions to identify and resolve issues
  • Clear accountability for developing the requirements and population specifications for the various data sets required to effectively support the future business processes
Given the new competitive business environment for utilities, radical changes are required in addition to the ability to replicate streamlined business processes within new utility acquisitions. The extent of this standardization will be dependent on the strategy to standardize supporting systems.

Business Solution Architecture Development
The various steps in the development of the optimized business solution architecture are defined in the section below.
  1. Strategic Direction

    2. The BSA for the program is developed based on:

    • Aligning cross-departmental objectives with greatly improved business benefits
    • Knowledge of the available/selected technologies and their capabilities and limitations
    • Identification of the scope of various types of work the processes need to cater for
    • Identification of the many system islands that need to be eliminated due to the expensive duplicate data entry and resulting data inconsistencies
    • Identification of the legacy systems that support the "blunt" areas of the business, which need to be retained as they are not cost-effective to replace
    • The development of an integrated and elegant system architecture

  2. Required EDRP Technologies

    3. For a utility, the suite of IS/IT technologies that can enable vast improvements in key Energy Delivery Resource Planning (EDRP) business processes include:

    • Geographic Information System (GIS)
    • Outage Management System (OMS)
    • Mobile Workforce Management/ Mobile Data Terminals (MWM/ MDT)
    • Distribution Planning & Analysis System (DPAS)
    • Supervisory Control & Data Acquisition (SCADA)
    • Customer Relationship Management (CRM)
    • Customer Information System (CIS)
    • Energy Reading Management System (ERMS)
    • Work & Asset Management System (WAMS)
    • Materials Management (MMS)
    • Contracting Management (CMS)
    • Purchasing Management (PMS)
    • Accounts Payable (AP)
    • Financial Management and General Ledger (GL)
    • Human Resource Management (HRM)

  3. Meaningful Business Requirements

    4. The key end-to-end business processes are refined within the framework of a best practice Integrated Business Process Model (IBPM). This IBPM is used to define the high-level functionality, usability, and interfacing requirements for the program scope. The system interface requirements take into account the appropriate system to process mapping and the resulting data flow volume, concurrency, and timing requirements.

  4. Technology & Vendor System Selection

    5. Enabling IS/IT technologies should be objectively evaluated and selected based on the support they provide for the enterprise's end-to-end business process scenarios. Fit to business process scenarios is a far more effective criterion than the more traditional demonstration of functionality. The evaluation needs to weigh "essential" requirements far higher than "nice to have" requirements. It also needs to identify any showstoppers. User evaluation ratings are multiplied by the previously agreed weighing factors to provide an overall business requirement rating. A similar process is followed for the other product criteria, such as:

    • Technical architectural fit
    • Vendor stability
    • Cost

    These product criteria are again combined using previously defined criteria-weighing factors to provide the final product ranking. The business requirement rating will generally have the highest criteria-weighing factor. Provided the products meet the minimum acceptance level, they are short-listed for inclusion into the vision system architecture.

    As the business moves through the solution architecture/vendor selection process there are some important considerations for management to evaluate. There are trade-offs between individual system functionality and the contribution to the support of end-to-end business processes and the number of integration points required to integrate the system into the overall system architecture. It is therefore important to evaluate the individual ratings of the individual systems plus the overall system integration rating, considering the suitability for the proposed integration strategy. From an integration strategy point of view, it has been found that where more than four major systems are to be integrated, it can be more cost-effective to move to a middleware integration strategy (compared to the point-to-point interface strategy).

    For the major system requirements, Commercial Off-The-Shelf (COTS) systems have much lower lifecycle management costs than custom development. COTS systems also are able to be implemented more rapidly than custom development and provide a much improved business case. COTS systems also have the advantage of having an evolution path that provides ongoing system release enhancements the business can take advantage of when it makes business sense. The size and diversity of the COTS user community, plus the vendor's development commitment, will determine the continued suitability of the systems to be selected. Also, it is important to limit custom enhancements to an absolute minimum to contain future upgrade cost.

    There are also some generally accepted trade-offs between how many best-of-breed systems need to be selected and integrated for a cost effective business solution. The selection of too few systems generally results in a loss of required functionality compared to the more focused COTS systems. For progressive and competitive utilities, there are no "enterprise systems" available, where they satisfactorily meet the focused processing needs covered by the EDRP technologies listed above. Where vendors or consultants say they have "THE enterprise system solution", it is recommended the support for the processes covered by the list of EDRP technologies be evaluated and that a list of reference sites be requested and visited where the scope of business processes and scope of implementation can be demonstrated. When making vendor selection decisions there may be a temptation to select a very large integrated enterprise system with plans to customize certain modules in order to "add back" some of the needed processing power of the best-of-breed systems. The lifecycle cost of the selected scope of customization has a major impact on the lifecycle cost and business case. It is recommended that add-on functionality/customization to the basic product functionality and data structures only be undertaken where it is essential and cost-effective.

    The overall cost-effective system architecture needs to be developed at the large EDRP level. The appropriate system to be used to support each IBPM process is identified based on the end-to-end business process scenarios and assigned user roles (not just because a system has a certain functionality should it be used!). (This previous sentence is unclear.) This analysis defines the system partitioning and likely interfacing requirements.
Business Release Planning
  • First Business Release

    • It is often impossible to effectively implement more than a few supporting technologies at a time, due to the capacity any business has to manage change at one time. However, it is true that implementing one product at a time provides far fewer business benefits than a synergistic set. Cost benefits are greatly increased when complementary technologies are implemented and integrated within a short space of time. This is because of the synergy these technologies provide in effectively supporting the workflow along major sections of some key end-to-end business processes. A business release scope (BR#) may also be selected to only support a sub-set of the business process work types until some later BR# completes the full work-type scope.

    When the most cost-effective suite of products to support the first Business Release (BR1) is implemented, the relevant baseline definition for the BR1-BSA is developed. It covers the scope, process architecture (IBPM), and system architecture to be developed during the first business release.

  • Subsequent Business Release Planning

    • Business release scope and phasing is developed based on the business requirement dependencies, system capabilities, integration requirements, and related data requirements. The relatively long time to appropriately configure, populate data, and integrate a utility facilities database using GIS technology clearly illustrates the required business release timing dependency. The scope, dependency sequencing, and timing of the various business releases are defined. The BSA includes sections that define the BR1, BR2, BR3, etc., business solution architecture baselines. These together with the vision solution architecture form the phased implementation plan.
Business Release Development
  • Detailed Functional & Integration Requirements

    • Using best practices experience, detailed end-to-end business processes are then developed to support the various types of work. An example of this is the objective to incorporate operational data maintenance into day-to-day operational business processes without post-capturing.

    The various product configuration (codes and preference settings) are agreed to in principle and tested to ensure a workable business solution for the full range of work-types to be supported. Essential work-around and customization needs are motivated. High-level incremental business case impact analysis of customization and add-on functionality needs are evaluated. This together with the appropriate timing determines the prioritized list of customization and add-on functionality that will form the scope of the various business release solutions. The detailed integration requirements are then defined. Changes to the previous baseline of the BSA need to be motivated as part of the requirement definition. Operational test scripts and acceptance criteria are developed based on these end-to-end business processes.

  • Detailed Data Requirements
    • In parallel with this step, the data requirement specifications and acceptance criteria need to be defined based on business concepts and terminology. The data rework and clean-up activities need to be identified and planned for in the program plan to ensure the appropriate business experts are available to perform this work. These people need to be the people who in the future organization will be responsible for managing the various core data sets. Data quality is critical for end-user acceptance of the business solution and for commitment to achieving the agreed business benefits. Inaccurate or incomplete data cause users to blame the system; to not use it and revert back to their previous systems. This will cause an ineffective solution implementation and will only be resolved when the executives accountable for the data sets are made to sort out the problems.

    These types of problems emphasize the importance of executive management buy-in and commitment to the business solution and the appropriate allocation of accountabilities for data, systems, and business processes defined in the BSA.

  • Detailed Design Specifications

    • The detailed design phase follows with clear traceability to the business requirements. Version changes required to the previous baseline of the BSA System Architecture needs to be recommended for approval. It is during this phase that the detailed configuration specification of the commercial products is determined and tested for full consistency across the various business processes.

    Having defined the BSA and detailed business requirements enables the detailed design specifications to be developed most effectively. It eliminates much of the architecture changes and resulting rework associated with product or department-focused solutions.

    In parallel with the detailed design phase, the data population specifications need to be finalized and executed. The data conversion, testing and loading specifications need to be defined in detailed data modeling concepts and technical terms.
Conclusion
A major business transformation program requires a number of specialist skills and indepth experience of the business processes and available technologies. The transformation planning needs to include an indepth understanding of the peculiar issues associated with each of these technologies and their effective integration. It is recommended that a third-party independent system integrator be engaged to support the utility through such a major business transformation program.

The development of a BSA document that provides the overall strategic direction and roadmap for the approved business transformation program and various business releases is essential.
© GISdevelopment.net. All rights reserved.