Enterprise Information Technology (IT) organizations seem to have a deep desire to create Technology and Architecture Roadmaps. The rational of creating these roadmaps is to help ready an organization for known and potential changes in technology as well as identify gaps in the ability to meet future requirements.
Unfortunately, too often the rush is to understand the elements of technology, such as the latest speed and number of cores for a processor in a blade center, and not how these technologies solve business problems. The difference is that the first are Engineering or Technology Capabilities, and the latter are actual Services.
Commercial IT service providers, such as the major telecommunications service providers, understand the linkage between technology and business implicitly and use several basic questions that lay the foundation of the purpose of a Technology Roadmap:
- What are the IT services that my customers need?
- What are the potential technical solutions, and what are the trades in cost, performance, delivery, and ultimately customer satisfaction?
- What is the Concept of Operations (CONOPS) for how the IT service is going to be delivered to my customers?
- Is my organization and processes mature enough to bring technology and the CONOPs together?
A commercial provider examines the first question and begins to decompose from the customer need into functional areas that combined together make the complete service. Contrast this against many IT organizations, which may be lead by engineers who are not directly in touch with their customers and make technology and service decisions that relate to their parochial understanding. This missing piece here is a close understanding of the customer, and not anecdotal information that may lead to decisions that are not based on real requirements or needs.
The second and third items are the critical transition from an engineering solution to a service solution. Engineering organizations are generally concerned with whether a service is going to work, the details of the component selection, and a deployment. They generally hold in lower regard the operations staff in an organization. The thought process of the staff sees the complexity of the developed solution as too complicated for anyone but a certified engineering genius to operate. Well balanced IT organizations know that the ability to ensure high-quality, repeatable service delivery is the goal – not just the excitement of the initial deployment of a technology or capability. The balance between engineering and operations must be found. That is, developing a forcing function that identifies how a new or enhanced service is delivered as well as the overall framework for all services to be delivered.
Giving it up – it is painful to stop what you are doing and rely on others. However, this is the key to the last item. The mature organization, like leadership itself, understands that the various divisions (e.g., engineering and operations) take leads at different times. The engineering staff will want to continue to “hug” the technical baby. The operations staff will tend to want to respond only to monitoring services and performing basic break fix, all too happy to leave the heavy lifting of configuring and provisioning services to the engineering staff.
So, how do you make sure that an IT organization is balanced (that is find the forcing function) and enables the development of technology, the creation of the service CONOPs, and the proper transition of these elements into a production environment? The simple solution is to find the junction between customer needs, engineering, and operations and to then assign the responsibility of this position in the middle, to a product organization that lives only thought the ability to ensure the mutual satisfaction of the other three elements. Mature service providers, such as large multi-service telecommunications providers, have well established product managers.
These managers are the fulcrum, the center of the development of an effective technology and architecture roadmap. The manager’s role is traditional leadership as in many cases the person may not be the position leader of all the people involved. Leadership is needed to provide a vision to the key individuals of the other organizations, and provide the environment for collaboration to develop effective and actionable roadmaps. The product leadership needs to direct, although not specify, all aspects of the roadmap activity:
- Development of the Architecture Roadmap, with the milestones of technology, services, and operations ensuring the collaboration of the engineering and operations groups
- Development of the business case, ensuring the appropriate inputs from the various organizations, including executives and finance
- Drive the endorsement and executive buy-in of the roadmap
- Development of a top-level actionable plan for the implementation of the roadmap
- Supervision of the implementation plan, with the responsibility to identify the critical milestones needed across all organizations
- Tracking of service execution, delivery, projections, and customer satisfaction with the responsibility to coordinate resources, if necessary, to address growth and service issues
- Periodic updates of the roadmap for service improvement as well as service retirement
By following this approach, the services developed will have the right balance, ensuring that customer satisfaction is measured and tracked, that operations measures the performance of the services delivered. As important, is ensures that engineering is available for escalations necessary for service quality or delivery issues, and is able to spend time on implementing the next steps of the roadmap.
Thus, the Technology and Architecture Roadmap no longer lives in un-actionable isolation – a dream only invented to meet some corporate feel-good requirement. It provides, when combined with the proper organizational, services concept of operations, and product leadership, clear direction and participation of each functional area with the result being services that can be consistently and efficiently delivered with high customer satisfaction.
1 comment:
Can we find examples that point to where this works and where it doesn't, as a validation of the model put fourth here?
Post a Comment