Enterprise Architecture 

Innovation can be driven by business dynamics, and by IT initiatives & new or emerging technologies.

A Technology Plan should set out how the potential benefits of any technology are to be assessed through an evaluation process, and the treatment for new, alternative and upgraded technologies, in line with enterprise architecting practice.

The Technology Plan should:

• Set out operational and business strategies and objectives and map them to ICT technologies and techniques that can potentially contribute to the realisation of those strategies and objectives.
• Identify technologies and technology trends that have potential benefits.
• Set out the processes for assessing those benefits in operational and business terms.
• Set out the architectural framework for developing technical solutions so that they address specified organisational strategies and objectives.

Can too much formality strangle innovation? Probably. Enterprise Architecture's contribution should include the validation of ideas and concepts in line with real world practicalities, and working out the optimal means to develop and deploy them.

Recognition of aspects that underpin and encourage innovation is a good foundation:

Innovation Principles

• Innovation addresses specified strategies and objectives.
• Innovation is ongoing.
• Innovation is collaborative.
• Innovation is cultural.
• Innovations consider the End User .
• Innovations should produce tangible benefits.
• Innovation is the realisation of ideas and concepts.
• Innovation applies to all aspects of a Service.
• Innovation applies to all stages of a process.
• Innovation should not be strangled by over-management.
• Customisation drives Innovation*.

Characteristics of an innovative culture:

• Creativity, collaboration, and communication is structural.
• Knowledge Management is actively applied.
• Systematic innovation - "What gets measured gets done".
• Experimentation is encouraged.
• Skillsets. Personnel have experience,competence, creativity in business and technology. The Mircosoft "T" : breadth in many fields, and depth in one field. Balance of skills - innovators to BAU.
• It innovates and imitates.
• Customisation driving innovation.
• Tolerance of failure.
• There is nothing permanent except change. Human structures should always be open to changes.

*Customisation drives innovation, but it also adds to cost. Enterprise Architecture addresses customisation by using replicable and repeatable components (as its building blocks) that can be assembled in customised ways.

Capturing innovations

Benefits Realisation

Benefits realisation is the process of realising the expected value from a newly created or changed capability through its whole life cycle; that is, from the inception of a technology change idea to the point where a capability is set-to-work and is managed through its operational lifecycle to decommissioning. It is the mechanism to realise the value from that program of work.

A Benefits Realisation Framework (BRF) approach can adopt concepts from models and frameworks such as the Val IT 2 model from ISACA, the UK Government methodology Managing Successful Programs (MSP and the PRINCE2 'stage gate' decision commitment model.

The BRF defines the relationship between a program and a customer's business and those in its organisation with governance responsibilities. Consequently the BRF supports the innovation and change opportunities by offering an investment trade off-analysis cycle which develops into a expected portfolio of ICT-enabled capability investments; placing particular emphasis on the definition of relative priority for high value opportunities, key financial indicators, the quantification of both hard and soft benefits and appraisal of the impact of not actively harvesting value.

Stage Gates

The BRF uses a series of stage gates to ensure strategic intentions and the value associated with them are not lost through the planning and definition stages of a project. Stage gates relate to the iterative funding commitment approach applied to each project within a program, where the extended program life-cycle will see a range of technology change opportunities and new projects being launched. The approach is applicable at both program and project level and is used to continually test that the proposed project, or initiative, is still able to deliver against the required program outcomes, strategic business value and should continue.

Architecture Definition

Architecture Definition is the logical assembly of all of the architectures represented as Viewpoints and Views, and the relevent standards, specifications, principles, taxonomy/ontology and reference models.

Viewpoints and Views.

The definitions of these two concepts are somewhat convoluted in the various frameworks' literature. Simply, but not simplistically, they are:

• A View is a representation of an architecture. Architecture Views may be graphical, tabular, textual or any combination of these.
• A Viewpoint is the perspective taken - for example, a CFO will have a different Viewpoint than a CIO or business manager. In other words, an architecture is represented in a View that suits the audience's Viewpoint.

The value of Views and Viewpoints is that they are techniques for representing architectures to stakeholders (and inherently, the development of a design and its rationale), abstracting essential information from the underlying complexity and presenting it in a way that maintains coherence and consistency. And they provide reference artifacts for future architecture work and changes.

Architecture Principles are the set of rules to guide business, information and technology decisions. They apply to the initial solution design, and across the lifecycle of any Service and its components through incorporation into change procedures.

Principles provide an agreed reference or policy to be used for evaluation of alternatives and as the basis for decisions. The Principles relative value may vary based on a particular decision to be taken.

A Taxonomy is a classification scheme and sets out how the various components and elements of an ICT environment are structured and inter-related.

An Architecture Ontology defines the architectural terms and definitions that will be used so that a common understanding of those terms can be established.

Technology Roadmap

A Technology Roadmap can form one part of a broader Technology Plan that documents the technical definitions, standards, reference models, policies and governance applicable to the technologies that are to be deployed over time.

The Technology Pan should set out architectures within the timeline dimension, from Baseline to Future State:

• Baseline. The current-state architecture ('as-is'), at a level of detail that provides for an understanding of what is being changed and the rationale for the change(s).
• Transitional State. Variations to the Baseline representing the stages to a Target architecture where components are introduced incrementally and need to interwork with legacy components and pending new components.
• Target State. The defined end state ('to-be') for which specific design efforts are undertaken. Once implemented, the Target State represents a new Baseline. A new Baseline architecture ideally forms a foundation from which further ICT transformations are enabled, and from which ongoing enhancements, developments and innovations can be applied as they are substantiated.
• Future State. Representing aspirational concepts that may not be currently realisable due to constraints such as budgets, resources and immature technologies etc . They provide for long term planning in line with long term strategies. Such architectures are not fixed, they are a part of a technique for considering longer term objectives in ongoing design efforts, and to align design with longer term aspirations. They are subject to ongoing change, and they represent a state that may never be reached.

It is the Future State architecture that can form the basis of a Technology Roadmap. A Technology Plan should incorporte potential Future State architectures of systems and component technologies in line with an organisations' wider ICT strategies and objectives, as a Technology Roadmap .