Building a Scalable Blueprint for Your BPM System
Last month, I began a series on the life cycle phases - analysis, design, construction and deployment - of a business performance management (BPM) project. This column continues that series and focuses on the design phase.
The design phase of the BPM project is where the blueprint for the final system is drawn. It's where you turn the requirements gathered in the analysis phase into a flexible, scalable system that will be able to grow with the organization. The design created here will be the plan for the entire BPM system, both when it's implemented and into the future. Therefore, if the project team does its job right, the system will provide the organization with top-notch analysis capabilities that will allow it to make timely and accurate decisions.
As discussed last month, the work on any IT project can be divided into three tracks: a user track, a data track and a technical track, and work in each track can often be simultaneously performed. Dividing the work this way saves time; but, more importantly, it enables the project team to ensure that each component of the overall system (human, information and hardware) is given equal attention. Then, it's a matter of mapping tasks to tracks.
The user track is where the team designs the information delivery mechanisms, specifically the user interface and reports. This is also where the behind-the-scenes user functionality - such as the semantic layer, data dimensions and facts, and drill-down paths - is mapped out. Data integrity requirements and system security mechanisms are also developed in this track. From these tasks, your deliverables should consist of a detailed layout of all predefined reports and ad hoc screens, along with security and data integrity specifications for the data management and database administration teams.
In the data track, the project team continues to analyze information requirements to develop in-depth business and technical meta data requirements. The team also conducts a data quality assessment using agreed-upon criteria and develops a data quality remediation road map to rectify any gaps found in the assessment. The deliverables for these tasks should include a complete data quality assessment, along with a ready-to-implement data remediation road map. At this point, the project team should also have enough information to construct a complete, conceptual (entity-relationship and/or dimensional) data model.
In the technical track, the project team begins by assessing the impact of the BPM system on the existing IT environment and evaluating technology options for integration. It's here that the requirements for hardware, system and data architectures are laid out and the hardware and software for each technical architecture component are selected. The deliverables for this track obviously include the final technical architecture design for the overall system. They also include detailed operational requirements and a capacity plan, as well as vendor and tools selections.
There is one important thread that runs through all these tracks and their corresponding tasks: scalability. It's absolutely critical that, from the outset, the BPM system has scalability designed into it so the system can grow as your organization grows and can provide for ever-changing information needs.
The need for scalability also affects the other tools you choose. For instance, the ETL tool must be able to handle large data movements and heavy scheduling and data loads. The server(s) you choose must be extremely scalable. As the system grows, it must not get bogged down because of slow processing and data transfer times.
One more caveat: During the design phase of the project, most of the work will take place out of the day-to-day eye of the user community. Thus, it's important to keep the executive sponsor excited and keep the relationship with the community at large on the front burner. Consult the appropriate people in the user community on the design of the system where feasible. Future users need to be involved in places other than just at the requirements stage; they need to feel it's "their" system. If the users feel they have input and ownership of the system, it has a much better chance of acceptance when it is rolled out. Remember, design flexibility into the system and keep everyone involved in the process, and you'll be designing success into the project from the get-go!
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access