My last section on roadmaps ends with technology roadmaps. Part 1 focuses on the types of roadmaps and their relationships . Part 2 focuses on the capability roadmap and part 3 focuses on the product roadmap . So now we wrap it up with the most complex roadmap.
A technology roadmap is a proposed future of technology being implemented by an information technology (IT) organization. Technology is an important aspect of every company today. This technology roadmap is designed to help plan the future through structural analysis. It's complex because it has many inputs, potentially including a lot of technology.
Inputs to a technology roadmap include the two roadmaps we discussed earlier (capabilities and products), strategy, previous technology roadmaps (if they exist), and the current state of the architecture . The technology roadmap is downstream of all other roadmaps and strategies, but it is also a feedback provider for other roadmaps. To align technology execution with business planning, give and take must be considered. This is why a technology roadmap is so important: it takes ideas and validates their viability.
This give and take depends on two constraints: budget and available resources . Budget planning can be difficult. There is always a need to control costs, but at the same time, you need to invest in the future. This is where strategy and capability roadmaps are important . They provide a lens through which budgetary decisions can be executed. Budgets limit what can be done. Which capabilities are most important to implement? What technologies are really needed to support these functions? What is the return on investment?
The latter question can be difficult to answer. Traditionally, ROI has been analyzed on a project-by-project basis. But when we talk about technologies and capabilities, a single project may span capabilities, or a capability may require several dependent projects to achieve ROI . It's not a one-to-one benefit payout, which makes analysis more difficult. It's a complex juggling act, and the tools to aid in juggling are not readily available (except for the human brain).
As mentioned above, another dependency is resources . For technical projects, this is usually HR - do you have the in-house expertise to get the job done? Are there resources in your market that you can hire (permanently or as a contractor)? And even then, do they have enough management bandwidth or maturity to take on the project. Organizational issues are important when discussing taking on new technology projects -- and it's not just about IT organizations, either. Business personnel may need to be educated or augmented to support the technology. At the very least, project timelines may need to be extended (especially if custom development is required) so that resources can meet demand.
Like all other roadmaps, a technology roadmap defines the technologies to be implemented over time . I would give the same answer as to how far in advance the technology roadmap should be : it depends on your business needs . Some businesses require longer planning cycles than others, requiring significant capital expenditures over extended periods of time. Others have more modest requirements and don't require such long planning horizons. Whatever that time frame is, it's going to be more predictable for the first few years and then get more murky as the timeline gets longer.
With all that said, how do we actually develop a roadmap? It's not easy, and it's not an exact science. The 10 steps include:
From the capability roadmap, identify the technologies needed to support the capability. Initially this is just a list - we'll get to that later.
Let's do the same with product roadmaps. Identify the technologies that need to be implemented. Again, just a list.
Sort your tech listings by theme and epic. A topic is a generalized strategy, while an epic is a more detailed part of a strategy. This step is somewhat optional, as long as the technology can be relevant to the strategy. It can be complicated because a technology can be part of two different epics or themes.
If you do not have a previous technology roadmap, then you will need to identify all current technologies and efforts, and project future maintenance, licensing, support and development costs and resource requirements. Hopefully you will have a previous roadmap to continue, but perhaps some work to get the data.
From the list of technologies, identify the specific technology. Are you using Microsoft Azure Synapse or AWS Redshift or Snowflake? This is the technology selection phase. It doesn't have to be perfect, especially if the product needs to be implemented in the future. Part of this effort should include the question of whether you build, buy, or rent (SaaS, cloud computing, or outsourced development or services).
Start building out the details of the new technology. You will need to understand when they need to be delivered (obtained from the capability or product roadmap), how long it will take to implement (this defines the start date), the costs associated with them, and the resources required to implement and maintain them. Note that it doesn't need to be perfect. A rough order of magnitude applies to pricing, and perhaps setting the time frame to the nearest quarter or best month.
With the data above, you should be able to come up with a rough timeline. You should also have a good estimate of your monthly or quarterly costs and resource requirements. If you're like most IT shops, panic sets in when you see a huge price tag or an army to implement. Don't panic. . .However.
So, let's start subtracting. By adding all these technologies, some of your existing technologies will disappear. Determine when it will go away and reduce the cost and resources required to support these technologies. Remember to keep some overlap - switching rarely means that the technology being replaced is immediately turned off.
So, are the numbers still too big? Now is the hard work. shake. There are many ways to make things fit. The first is to ask the wallet manager for more money. We all know how it works - but if you can tell a compelling story (and it's all about strategy, you have the data to tell a compelling story), you might have some luck. But before you ask this question, please verify your number. Is the fee correct? Are resource plans correct? Is there a cheaper but not optimal but adequate solution? Is there a cheaper temporary solution that works? Once everything is correct and verified, you have a few options: a.) Move the technical project further down the timeline. This means that other related projects may also be launched. b.) Stretch projects - can't do this for all projects; mostly custom software development work. c.) Remove items from the roadmap. When doing so, other technologies may also need to be removed. Any of these three options may require adjusting capabilities or product roadmaps.
After all this is done, the roadmap needs to be adjusted as needed. Data keeps pouring in. Projects slip, projects are completed ahead of schedule, disruption or new technologies come into play, events cause strategy changes. A constant focus on maintaining a roadmap allows businesses to stay more agile and react faster to develop strategies with less delay to events that require strategic changes.
The process is not perfect. A particular problem is in agile processes. Companies need agility and have jumped on the agile bandwagon. A roadmap, as the name suggests, is making a plan - that's not agile. So, how is this reconciled? In short, it isn't, at least as far as I know. But if I find out, I'll let you know. One thing I do know is that it is possible to make high-level estimates and an attitude of accepting change and going with the flow.
| This article | https://jiagoushi.pro | |
| Discussion: Knowledge Planet [Chief Architect Circle] or add WeChat trumpet [ca_cto] or add QQ group [792862318] | ||
| No public |
【jiagoushipro】 【Super Architect】 Brilliant graphic and detailed explanation of architecture methodology, architecture practice, technical principles, and technical trends. We are waiting for you, please scan and pay attention. |
 |
| WeChat trumpet |
[ca_cea] Community of 50,000 people, discussing: enterprise architecture, cloud computing, big data, data science, Internet of Things, artificial intelligence, security, full-stack development, DevOps, digitalization. |
|
| QQ group |
[792862318] In-depth exchange of enterprise architecture, business architecture, application architecture, data architecture, technical architecture, integration architecture, security architecture. And various emerging technologies such as big data, cloud computing, Internet of Things, artificial intelligence, etc. Join the QQ group to share valuable reports and dry goods. |
|
| video number | [Super Architect] Quickly understand the basic concepts, models, methods, and experiences related to architecture in 1 minute. 1 minute a day, the structure is familiar. |
|
| knowledge planet | [Chief Architect Circle] Ask big names, get in touch with them, or get private information sharing. |
|
| Himalayas | [Super Architect] Learn about the latest black technology information and architecture experience on the road or in the car. | [Intelligent moments, Mr. Architecture will talk to you about black technology] |
| knowledge planet | Meet more friends, workplace and technical chat. | Knowledge Planet【Workplace and Technology】 |
| 【Super Architect】 | smart moment | |
| Bilibili | 【Super Architect】 |
|
| Tik Tok | 【cea_cio】Super Architect |
|
| quick worker | 【cea_cio_cto】Super Architect |
|
| little red book | [cea_csa_cto] Super Architect |
|
| website | CIO (Chief Information Officer) | https://cio.ceo |
| CIOs, CTOs and CDOs | https://cioctocdo.com | |
| Application development and development platform | https://apaas.dev | |
| Development Information Network | https://xinxi.dev | |
| Chief Architect Community | https://jiagoushi.pro | |
| super architect | https://jiagou.dev | |
| Enterprise technical training | https://peixun.dev | |
Thank you for your attention, forwarding, likes and watching.