Play 3 – Build Simple Governance, Anchored Around Applications Then Technology
- Difficulty: Moderate
- Target time: 6-10 weeks
- Maturity: 1 to 2 2 to 3
- Need to control technologies in the enterprise A desire to control cost
- Desire to reduce applications or technologies being used
- People creating/buying applications for capabilities which existing applications have
- Lots of duplicate technologies being used
- A broad list of applications, even if disparate and not 100% complete
- Communication to relevant IT teams from senior leader
- Engagement of the impacted teams, or awareness
- Communicate the objectives to the impacted teams, engage and gain input on the scope of governance
- Define architecture principles
- Capture the application list
- Communicate the principles:
- For applications being created or changed, teams should validate them against the principles
- Set a criteria for when teams must engage EA – keep it simple (e.g. major projects, key apps only, spend over X amount)
- Let teams generally self govern, engage projects informally to track adherence
- Capture applications costs to provide an anchor for discussion, and to help identify applications which must be referred
- Move to the technology layer (product duplication or standards) as the next step for governing
- Teams may be resistant to be governed at first but demonstration of value (pick some obvious wins) and exec backing of success will help gain traction
- Self-governance gives teams some freedom and EA is not seen as bureaucracy
- Teams see value when you present other options, or speed their delivery through having candidates ready for them
- CIO – success criteria, principles
- IT Management – principles, team engagement
- Finance – costs
- Engage and regular updates with the CIO
- Monthly report on adherence
- Engagement and reviews with teams
- Monthly review for 2/3 months with IT management to get feedback on the process
- Enterprise Architecture seen as proactive but not bureaucratic
- Role of EA beginning to be understood by the wider organisation
| Steps | A1.1 | S1.1 | S1.6 | S1.5 | T1.1 | T1.2 |
|---|---|---|---|---|---|---|
| What | Capture the applications with basic details and services | Define a set of achievable architecture principles to govern against | Create a governance process against which to maintain data in Essential and monitor alignment | Capture costs against the applications in the architecture | Create the technology reference model | Capture the technology products against the reference model |
| Usage | Have a list of applications used that can be the anchor for the rest of the work. Define strategic applications in line with your target state | Engage projects with the principles at start-up and decide architecture against the principles. Break the principles only where there is a compelling reason | Use the process to engage projects, get data updates from projects and to review changes against the principles (standards can come later). Keep it light touch and initially let projects do some self governance. | Costs will be key in starting to highlight high cost applications so rationalisation opportunities can be better identified and compelling business cases built | Anchor for technology Products created | Identify duplicate and high risk technologies |
| Interested Parties and expected response | Business & IT Interested but not excited | CIO Interested, keen to know how the principles will help them achieve strategy. Projects Positive if the principles are reasonable | Projects Participation, a good process should see active participation by projects | CIO & Business Active interest, visibility of unnecessary cost always engages | CIO Interested but not excited | CIO Initiates activities based on duplicate technology or risk |
| Approach | By Business Unit/Area | Overall Enterprise | Overall Enterprise | By Business Areas | Overall Enterprise | Overall Enterprise |