Fragmentation is propagated in a number of ways and areas of the business. You may recognise some of them: ‘Organisation’ – a lack of coordination between the teams involved in designing, developing and operating IT systems can result in friction, lack of co-operation and occasional conflict. Different environments, such as Windows, UNIX/Linux and mainframe can be treated as if they were different worlds, with the parties involved becoming almost tribal in their attitudes to each other. Planning and financing: ‘Too many cooks’ – historical convention or organisational politics can combine to out-rank objectivity when there are too many different parties involved in infrastructure decision making processes. If everybody has to have their say, there is a good chance of inappropriate viewpoints skewing things out of kilter.‘Operations’ – coordinating policy, performance, management, support, troubleshooting and so on across technology and departmental domains is fraught with challenges. Technically, it is difficult to achieve consistent performance, scalability and security, and the time and effort spent on communicating and co-ordinating between teams adds overhead. ‘Skills and resourcing’ – Resource and effort can be duplicated in some areas and stove-piped in others. It can be manifest by people doing essentially the same things but following different processes and using different tools, or it could be an imbalance of skills in certain areas due to IT staff being locked into specific kill sets, perhaps as a result of some of the influences outlined above. The net result of fragmentation is inefficiency and waste. The risk of doing the wrong things (or just doing things wrong) is heightened, time is lost that could be better spent and, worst of all, hard-won budget may be used unnecessarily.
You don’t often see one of these!
From an IT perspective, service delivery relies on each layer of technology integrating with each other in an efficient manner, supported by appropriate monitoring and management.
From the outside in, to business users IT service delivery should very much appear as a black box. This way, attention can be focused on the ‘services’ rather than the “what’s inside the box”.But hang on... Isn’t that just a mainframe?
Given all of these developments, it is possible to take such a mainframe view and marry it with the flexibility and control that the more recent platforms lack, building on what is available now but without falling into the traps of the past?
2. Agenda<br />The challenges of IT delivery today<br />Bringing things up to date<br />Starting with the end in mind<br />What about Mainframe? <br />
3. IT is not broken – but it’s not always easy!<br />“How well do you think IT helps the business achieve its strategic and operational goals?”<br />
4. Organisation<br />FRAGMENTATION<br />Planning and <br />Financing<br />Skills<br />Operations<br />Fragmentation is the bane of IT today<br />
5. Meanwhile, new pressures and requirements force change<br /><ul><li>“What business drivers are having the most impact on how you architect and operate your server estate?”</li></li></ul><li>No organization has the luxury of a green field site…<br />
6. IT SERVICES<br />Bringing things up to dateThe Technology View…<br />SOFTWARE<br />ARCHITECTURE<br />SYSTEMS MONITORING AND MANAGEMENT<br />PLATFORM<br />CAPABILITIES<br />HARDWARE<br />PLATFORM<br />
7. IT SERVICES<br />The Business View<br />INFORMATION<br />TECHNOLOGY<br />
8. Building a picture of service delivery<br />Adopting a ‘portfolio approach’ to IT<br />Taking an inclusive view of existing capacity<br />Making the right decisions<br />Rationalising at the right level<br />Starting with the end in mind<br />
9. Consistent policies<br />An architectural view of IT delivery<br />Co-ordination between development and operations <br />Management of technical knowledge<br />Getting to grips with costs<br />Right tools for the job<br />Building a picture of service delivery<br />... The ‘portfolio approach’ does applyto IT!<br />
10. Cost of acquisition/allocation<br />Storage cost and flexibility<br />Software licensing costs<br />Ease/cost of operational management<br />Inherent security<br />Ease/cost of security management<br />Performance and scalability<br />Resilience and recovery<br />Application support<br />Standards support<br />Taking an inclusive view of existing capacity<br />
11. Making the right decisions<br />REVIEW OF CAPACITY<br />USE<br />EXISTING<br />NEW REQUIREMENT<br />EXTEND<br />REPLACE<br />POTENTIALLY<br />INCREASING<br />COST AND<br />EFFORT<br />BUILD FROM SCRATCH<br />
12. What about the Mainframe? Running costs based on availability of existing kit:<br />cents / hour<br />AMAZON EC2<br />SERVER<br />MAINFRAME<br />
13. Rationalise at the right level<br />Development <br />Operations<br />Communications <br />Skills<br />Architecture<br />IT today is about striking the right balance between existing and new<br />Look for quick wins, free up resource to enable breathing space <br />Conclusion<br />