Showing posts with label IT strategy. Show all posts
Showing posts with label IT strategy. Show all posts

2013-04-06

Enterprise patterns: Strategy Implementation Chain (SIC)

The aim of this post is to synthesize some enterprise patterns recently published in this blog to address the practical enterprise need of “strategy implementation”. The arrangement achieved links different #entarch artefacts into some kind of chain of transformations, with its supervision and enabling:
  1. from the business objectives to a portfolio of projects (or roadmap); 
  2. from the brief initial project specs to a prototype; 
  3. from a prototype to a deployable solution (processes and services); 
  4. from a deployable solution to a deployed solution (by deciding where to deploy each service, e.g. in-house or in-cloud, IaaS, SaaS, PaaS, etc.); 
  5. EA supervision of projects; 
  6. platform-enabled agile solutions as an implementation enabler; 
  7. melting pot of #entarch+#bizarch+#BPM+#SOA+#ECM+#ITIL+#governance+#strategy as a methodology enabler. 


And resources which describe the parts of the chain.

1. Enterprise pattern “Strategy TO Portfolio” (STOP)


2. Modelling of explicit and executable business processes


3. Relationship between EA, PMO, an SDLC methodology and ITIL


4. Enterprise pattern “#Cloud-Ready Estimation and Evaluation Procedure” (CREEP)


5. Relationships between EA and PMO


6. Enterprise pattern “Platform-Enabled Agile Solutions” (PEAS)


7. Melting pot


The use of SIC enterprise pattern can help to avoid some risks in EA practice. (The list below is taken from a recent LinkedIn discussion http://www.linkedin.com/groups/What-are-potential-risks-in-36781.S.232446262 )
  • Incorrect understanding of business strategy
  • Incorrect translating from strategy to architectural design
  • Not Balance well on EA aspiration & EA Practicality
  • "Waterfall" type of EA, lack of Agile practice - Incremental-ism, Improvement and Iteration.
  • Framework or Frameless? How to leverage well?
  • "We know what we are doing, even though we've never done it before"
  • "We just need a tool"
  • No focus on delivering quantifiable value
  • Too focused on IT
  • "Modeling the Universe"
  • "Let’s collect data and see what we find"
  • EA Dept hoarding information
  • Unable to articulate the value proposition of EA
  • Unable to communicate effectively with stakeholders
  • Unable to execute in an appropriate risk management approach that matches effort (investment) with return
Thanks,
AS

Enterprise patterns: Strategy To Executable Portfolio (STEP)

This pattern is based on previous blog posts about linking business priorities and IT portfolio of projects - http://improving-bpm-systems.blogspot.com/search/label/IT%20strategy .

Considering that at present the intended strategy is only a part of the realised strategy, it is necessary to take into account emergent strategy as quick as possible.  Developing a strategy for 3 years and and reviewing it only once (mid-term review) is not sufficient. Strategy and related portfolio should be changed more often.

Another typical situation is "...strategy clarification, illumination ... " which is carried out after the approval of the strategy. So, such a strategy may be not "implemetable" at all.

The explicit linking between business priorities and IT projects (see illustration below from http://improving-bpm-systems.blogspot.com/2013/02/linking-business-strategy-and-it.html)

  1. guarantees implementation of the strategy, 
  2. simplifies the strategy review and 
  3. changes such a review into routine activity. 


Thanks,
 AS



2013-02-24

Linking business strategy and IT strategy

This post is a continuation of "Writing IT strategy - From business priorities to the planning of IT actions".

The main picture from the previous post is extended to explicitly link move concepts (business strategic objectives, business initiatives, business capabilities, IT capabilities (generic supply), IT tools (specific supply) and IT programmes.

The logic of linking is the following:
  1. each business strategic objective has its own corporate priority and is based on one or few business initiatives;
  2. each business initiative has its own corporate priority derived from business strategic objective;
  3. each business initiative requires a particular level of maturity of some existing or new business capabilities;
  4. each business capability has its own current level of maturity (can be determined by experts) and the requested level of maturity (so a gap can be identified);
  5. particular level of maturity for each business capability depends on a particular level of maturity of some existing or new IT capabilities;
  6. each IT capability has its own current level of maturity (can be determined by experts) and requested level of maturity (so a gap can be identified);
  7. each IT tool contributes into one or many IT capabilities;
  8. each IT tool has its own current level of maturity (can be determined by experts) and requested level of maturity (so a gap can be identified);
  9. each programme implements one or few IT tools, and
  10. priorities of programmes are defined by the contribution into business priorities.

This is a possible way to "...setting out your logic about a choice in advance..." as recommended in "Strategy Is All About Practice".

Those explicit links can help you to find leverage points (thanks to Ivo @kvistgaard for "a strategy is a choice of leverage points"; see also http://www.thwink.org/sustain/glossary/LeveragePoint.htm) so you can do more with less.

Keeps the links systematically updated (especially after compelting IT projects) and watch for new leverage points. A strategy adjustment and validation becomes a routine on-going activity during its implementation (like functioning of the GPS navigator).

Thanks,
AS

2012-06-27

Writing IT strategy - From business priorities to the planning of IT actions

This post is the continuation of the post "Writing IT strategy" -  http://improving-bpm-systems.blogspot.com/2011/09/writing-it-strategy.html

The explicit dependencies between business-specific initiatives, business-generic needs (or business capabilities), IT-generic capabilities and programs demonstrated in figure below allow to explicitly linking the business priorities with the planning of IT actions. The logic of linking is the following:
  1. each business-specific initiative has its own corporate priority;
  2. each business-specific initiative requires a particular level of maturity of some existing business-generic needs;
  3. each business-generic need has its own current level of maturity (can be determined by experts) and the requested level of maturity (so a gap can be identified);
  4. particular level of maturity for each business-generic need depends on a particular level of maturity of some existing IT capabilities;
  5. each IT capability has its own current level of maturity (can be determined by experts) and requested level of maturity (so a gap can be identified);
  6. programmes to close gaps are proposed, and
  7. priorities of programmes are defined by the contribution into business priorities.

Thanks,
AS

2011-09-22

Writing IT strategy


The IT strategy development logic is the following:
Business strategy -> business architecture TO-BE -> application + information architectures TO-BE -> technical architecture TO-BE -> IT (or EA) AS-IS -> IT roadmap

Main topics in the IT strategy document are the following:
  1. Executive summary (½ page – summary for senior management, e.g. the Board members)
  2. Business context (½ page – WHY the major directions in the IT strategy have been taken)
    • Strategic directions for the IT as an enabler for the company’s mission and vision
    • Potentials of the IT as a strategic driver for the company’s business
  3. IT contribution to business success (1 page - HOW IT capabilities and plans will contribute value to the business or delta in business is reflected by the delta in IT)
  4. IT guiding principles (½ page – rationales to guide IT decision making)
  5. Assessment of the current state of the IT environment
  6. IT Roadmap (WHEN and WHAT to reinforce and build)
  7. Etc.

Item 3 is illustrated by the following image:


Ideally, such dependencies can be generated from business processes and applications (i.e. from your EA repository).

In the real situation this illustration may become rather complex, so some techniques for better understanding can be necessary. For example, the selection of a rectangular highlights all connected rectangulars and links, as shown below:


And the final advise: be careful with arrows - people may interpret them differently.

Thanks,
AS