Thursday 18 November 2010
EA Maturity levels from Ross, Weill, Robertson - ‘Enterprise Architecture as Strategy’ (2006):
1. Business silos
2. Standardised technology
3. Optimised core
4. Business modularity
...well, probably on our way from 1 towards 2 and 3, but no where near 4 yet.
To keep following our EA maturity path will require closer alignment between the University's business and IT, and the ability to deploy enterprise-wide systems or alternative service delivery models, according to a strategic plan (enterprise architecure), controlled by an enhanced IT governance framework, facilitated by a dedicated Enterprise Architect.
Next steps, recruit Enterprise Architect. Start work on establishing enhanced IT governance framework and high-level analysis of enterprise as-is and to-be. Choose a suitable project (SITS improvement project or Document management and workflow) and get stuck-in.
There is a clear need to employ EA where their are overlaps (for example, Blackboard & SITS).
Use as a method to assess solutions - Review, remove, re-implement, re-use or replace, but according to an enterprise architecture strategy.
Needs to link-in with ITIL sevice strategy and service design .
Changes since initial EA Foundations programme event:
1. Enterprise Architect role internally advertised
2. Presented to Portfolio Executive on alternative service delivery models - they showed an interest in looking at HR & payroll area
1. Recruit Enterprise Architect
2. Build scenario for Portfolio Executive
3. Think about how to knit existing BA work with new, more holistic, EA approach
4. Obstacles - time
Tuesday 12 January 2010
What conclusions can I make looking from a Bristol context?
- There is a real focus at the University on saving costs. But in a sustainable way wherever possible
- Support Process Review is the main vehicle for looking at organisation and process improvements
- Enterprise Architecture at Bristol is more likely to relate to applications, data and technology domains rather than the business domain, and is more likely to be an approach rather than a distinctive project or programme - A part of our new IT Governance process
- A business case for FSD (or EA) is needed to communicate the possibilities and to secure organisation commitment
- Support Process Review is likely to expose new systems requirements - Meeting these requirements is likely to include better use of our existing CIS (SITS, Coda, Blackboard, Syllabus Plus, etc.)
- In an ideal world, we should be looking at all options for service (capability) development (including outsourcing, SaaS / Cloud, etc.)
- Risks of NOT doing EA - Inability to change quickly; Not meeting customer needs; Duplication for no good reason
- Managing Change - Still need to be able to innovate; Sell the benefits not the approach
Tuesday 5 January 2010
1. What strategic (institutional) priorities does FSD address?
- Links to relevant University strategy (vision, strategic plan, etc.)
- Current issues (financial crisis, public sector debt, etc)
- New opportunities brought by FSD (for example, opportunities for innovation and/or collaboration)
- EA or SOA specific project
- Business scope, systems scope or technology scope
- Embed FSD in existing processes
- What costs are likely to occur
- Risks of not doing FSD & risks of doing FSD
- Phasing to allow for confidence building
- Early wins
- Specific timescales
- Cultural issues to overcome
- Business / IT disconnect
- Lack of governance
- Wearing the FD’s hat
The results of the discussions are still being collated, and so Part 3 of this topic will attempt to distill the outcomes for the session.
Monday 23 November 2009
- Cutting costs at the same time as minimising the effects on the institution's sustainability
- Continued, sustainable, growth
All of the above highlights that the business case for FSD must be compelling, quickly show value, and will have a different scope at different institutions depending upon where they are now.
The business case for FSD cannot propose a large, all-encompassing project (or programme), that won't deliver for years. But is more likely to be a decision process that takes into account future capability (service) delivery requirements (ref. Guerilla SOA).
One way to evaluate a business case for FSD could be to use the Formula for Change created by Richard Beckhard and David Gleicher (sometimes called Gleicher's Formula):
D x V x F > R
D = Dissatisfaction with how things are now;
V = Vision of what is possible;
F = First, concrete steps that can be taken towards the vision.
If the product of these three factors is greater than
R = Resistance, then change is possible.
Because of the multiplication of D, V and F, if any one is absent or low, then the product will be low and therefore not capable of overcoming the resistance.
Whilst this formula was developed to assess the likely success of implementing change, I think it could also be used to evaluate the likely success of a business case.
- What are the challenges the institution is facing now that could be helped by FSD? How will these challenges change in the near future (think post-election 2010)?
- What opportunities could FSD bring that will address these challenges?
- How can value be demonstrated quickly?
- What resistance from senior management is likely to be encountered?
Friday 16 October 2009
The following SWOT analysis is based upon my perception of our As Is position for data and applications. However, this analysis needs to be confirmed by a much wider stakeholder group.
Note that the following is draft and incomplete, and is only available to University of Bristol. All comments welcome:
SWOT for As Is architecture (UoB only)
With more defined aims:
- Help universities and colleges to understand their evolving administrative and academic processes and requirements so they are able to make better use of their current systems, and fully understand the impact, cost and risk of change, and thereby identify what issues need to be addressed to better integrate their systems and to move to more appropriate and flexible modes of service delivery
- Help universities and colleges proactively engage with suppliers of administrative and academic systems to identify FSD solutions to these evolving institutional/consortia/sectoral needs
- Work in collaboration with suppliers of administrative and academic systems, informing them of the commercial advantages in offering SOA compliant systems to the sector, and to develop open systems and interfaces, and carry out pre-competitive R&D in collaboration with the sector so that their products are fit-for-purpose
Joining the STG has many benefits:
- A community in which to collaborate; to share experiences, knowledge, lessons learnt, common issues and challenges, and good practice solutions with others
- A framework in which to form cross-institutional partnerships
- Managed engagement and partnering with suppliers of administrative and academic systems to maximise the market potential for their systems and services
- Improved understanding of your administrative and academic areas of concern and requirements for supporting ICT systems, and of the impact, cost and risk of changing technical systems, supporting better use of current systems and more informed purchasing decisions for new ones
- Access to support, guidance and training
- JISC funding
In return, I have agreed to investigate the creation of a 'cluster' group to explore the 'Business Case for EA' and how to communicate to this to senior management.
Thursday 15 October 2009
Bristol has suffered in the past from a disconnected decision making process which for has resulted in piecemeal application development, little thought towards infrastructural software (Identity Management, Document Management, etc.), and tactical system integration.
However, things are changing for the better - A new IT Governance framework has been designed and (mostly) implemented:
This is very timely as we are embarking on a Support Process Review (BPM) exercise that will most likely introduce some significant new systems to support any new organisation and changed processes.
In the new IT Governance framework, the Programme Management group has the role of coordinating business cases and managing dependencies. It will be this group that advises the Programme Executive on architectural matters, ensuring that decisions aren't made in isolation from the information systems landscape of the University as a whole (the enterprise).
The Programme Management group will itself be supported by the ISYS Applications/Systems Development group, which will have responsibility for technical direction for data and applications to support the emerging business change requirements, whilst also feeding technology requirements to the ISYS Infrastructure group.
My aim before moving forwards with EA, is to line-up the objectives and communications paths of the ISYS Applications/Systems Development group with the new Programme Management group and the ISYS Infrastructure group.