The only thing that’s constant for most organizations is change. Today there’s an unprecedented, rapid rate of change across all industry sectors, even those that have been historically slow to innovate like healthcare and financial services.
In the past, managing ideation to the delivery of innovation was either not done or was relegated within organizational silos, creating a disconnect across the business. This, in turn, resulted in change not being implemented properly or a focus on the wrong type of change.
For an organization to successfully embrace change, innovation, enterprise architecture and project delivery need to be intertwined and traceable.
Peter Drucker famously declared “innovate or die.” But where do you start?
Many companies start with campaigns and ideation. They run challenges and solicit ideas both from inside and outside their walls. Ideas are then prioritized and evaluated. Sometimes prototypes are built and tested, but what happens next?
Organizations often turn to the blueprints or roadmaps generated by their enterprise architectures, IT architectures and or business process architectures for answers. They evaluate how a new idea and its supporting technology, such as service-oriented architecture (SOA) or enterprise-resource planning (ERP), fits into the broader architecture. They manage their technology portfolio by looking at their IT infrastructure needs.
A lot of organizations form program management boards to evaluate ideas, initiatives and their costs. In reality, these evaluations are based on lightweight business cases without broader context. They don’t have a comprehensive understanding of what systems, processes and resources they have, what they are being used for, how much they cost, and the effects of regulations.
Projects are delivered and viewed on an individual basis without regard for the bigger picture. Enterprise-, technology- and process-related decisions are made within the flux of change and without access to the real knowledge contained within the organization or in the marketplace. All too often, IT is ultimately in the hot seat of this type of decision-making.
While IT planning should be part of a broader enterprise architecture or market analysis, IT involvement in technology investments is often done close to the end of the strategic planning process and without proper access to enterprise or market data.
The following five questions illustrate the competing demands found within the typical IT environment:
Stakeholders place a large number of tactical and strategic requirements on IT. IT is required to offer different technology investment options but is often constrained by a competition for resources.
An enterprise architect provides a high-level view of the risks and benefits of a project and the alignment to future goals. It can illustrate the project complexities and the impact of change. Future-state architectures and transition plans can be used to define investment portfolio content. At the same time, portfolio management provides a detailed perspective of development and implementation. Balancing these often-competing viewpoints can be tricky.
Application management requires a product/service/asset view over time. Well-managed application lifecycles demand a process of continuous releases, especially when time to market is key. The higher-level view required by portfolio management provides a broader perspective of how all assets work together. Balancing application lifecycle demands against a broader portfolio framework can present an inherent conflict about priorities and a struggle for resources.
As many organizations move to small-team agile development, coordinating the various application development projects becomes more difficult. Managing the development process using waterfall methods can shorten schedules but also can increase the chance of errors and a disconnect with broader portfolio and enterprise goals.
Lifecycles such as innovation management, enterprise architecture, business process management and solution delivery are all necessary but are not harmonized across the enterprise. The connection among these lifecycles is important to the effective delivery of initiatives and understanding the impact of change.
Enterprise architects are crucial to delivering innovation. However, all too often, enterprise architecture has been executed by IT groups for IT groups and has involved the idea that everything in the current state has to be drawn and modeled before you can start to derive value. This approach has wasted effort, taken too long to show results, and provided insufficient added value to the organization.
Enterprise and data architects who relate what they are doing back to what the C-suite really wants find it easier to get budget and stay relevant. It’s important to remember that enterprise architecture is about smarter decision-making, enabling management to make decisions more quickly because they have access to the right information in the right format at the right time. Of course, focusing on future state (desired business outcome) first, helps to reduce the scope of current-state analysis and speed up the delivery of value.