Skip to main content

2006 | Buch

From Enterprise Architecture to IT Governance

Elements of Effective IT Management

insite
SUCHEN

Über dieses Buch

This book is addressed to IT decision makers who face the task of securing and exploiting the overall potential presented by their information systems despite budget constraints. It concerns itself with the task of establishing IT governance processes that ensure comprehensive control as one moves from strategic pl- ning to operational implementation. This task demands orien- tion and transparency, i. e. a management information system for the CIO. Such a system is available in the form of enterprise architecture (EA). EA delivers clear answers, it reveals deficiencies, illustrates the complex interaction of business processes, applications and infrastructure, and provides a foundation for the kinds of analysis that give us the right information and enable genuine IT gov- nance. The term IT governance is more than a mere buzzword. As an IT executive, one may sense that ones information systems are out of kilter and that it will be necessary to take action to avoid - ing treated as if one were a magic orange that continues to yield 1 juice no matter how often it is squeezed. While governance (or control) sounds like the right response, it is not clear where we should begin. Do we know exactly where the gears need lub- cation? Do we know where the rust has taken hold? The reports from the IT jungle are full of examples of tech- logical frivolity, heterogeneous infrastructure environments, se- ers running below capacity, redundant hardware, and superf- ous development tools.

Inhaltsverzeichnis

Frontmatter
1. Introduction: When Things Just Work
Abstract
A well-known commercial from the automobile industry uses the slogan: Isn’t it nice, when things just work? Doesn’t this slogan also apply to the IT support of your business processes, the alignment of your IT infrastructure and applications development to the strategies and goals of your enterprise? Isn’t it nice, when IT does exactly what it is supposed to do — and that cost-effectively, smoothly, and elegantly? My proposition is that this is exactly what the mysterious creatures known as IT architects are there to accomplish with their enterprise architecture (EA), i.e. to simply make sure that things work the way they are supposed to, the way the clients, system operators, and users like. I suppose this might elicit some protest on the part of IT professionals. After all, the clients, system operators, customers, and users do not always succeed in making their wishes clear.
2. Foundations: Finding the Starting Point
Abstract
On the first leg of our journey through the world of enterprise architecture (EA) and IT governance, I would like to offer a description of the main features that come into view, the landscape, the flora and fauna. This aim of this guidebook is to help us to better understand subsequent observations on the subjects of EA documentation, analysis, planning, implementation and control in the context of IT strategy and governance.
3. Goals: Doing the Right Things Right
Abstract
While few of my readers will be content with this familiar quotation from the aviation industry as a response to the issue of the costs and benefits of enterprise architecture (EA), it nonetheless offers us a kernel of truth: only the real flight, i.e. the real establishment of EA, will provide us with the facts we need to evaluate the costs and benefits associated with a particular case.
4. Documentation: Structuring Enterprise Architecture
Abstract
The classic definition of management is based on the assumption that things can be moved by systematic action, by a controlled circuit of planning, organization, control and navigation. As we are all aware, this presupposes information. How are we to plan, organize, control and, above all, navigate if we do not know where we are and where we would like to go? Any form of management is based on information, irrespective of whether it is a matter of our sales information system that enables us to direct sales activities and product development or our business intelligence suite that gives us an overview of all of the relevant indicators. If we would like to achieve a state in which things simply work, then we will have to actively manage development. This cannot be done in the dark.
5. Analysis: Evaluating Enterprise Architecture
Abstract
How much time, money and effort goes into your annual planning — the project portfolio, the prioritizing of projects, the consultations with the departments, the drawing of the red line that cancels the impracticable projects? And all of this with the aim of optimally aligning new developments and adaptive maintenance to the needs of the business. Truly admirable work!
6. Planning: Creating Enterprise Architecture
Abstract
Most organizations have a map of their applications environment and infrastructure systems. How up to date and accurate is your map? Is it also used for purposes of planning, i.e. does it include representations of multiple past and future states? Are you able to run gap Analyses of current and target states? Do you have a practice of aligning your project portfolio with the measures derived from the planning of the applications environment and the gap analysis? Does this or some other procedure allow you to ensure that the various measures of technical renovation (e.g. enterprise application integration) harmonize with the IT investment strategies of the departments in your organization and that are outlined in the project portfolio?
7. Implementation: Developing Enterprise Architecture
Abstract
It is the IT architects who are called upon to forge the first link between strategic planning and operational implementation when it is a matter of the development of the enterprise architecture (EA), when the strategic development planning is to be implemented, and when IT governance is on the agenda. What are the consequences of this task for the organization of the architecture management? How can we secure the thorough transformation of strategy into operational systems? What do the accompanying processes and boards look like? How do we secure results? What are the procedures and tools that will help us to do so?
8. Safeguarding: Controlling Enterprise Architecture Development
Abstract
What is the best plan worth if one does not succeed at controlling its implementation? What is the benefit of identifying consolidation potential (e.g. in the case of development lines) in ones organization if it is left unexploited, if reference architecture models are not specified and introduced as obligatory? What is the value of eliminating redundant development lines if the capacity that is saved is not sensibly re-channeled, for instance, in order to reinforce the innovative strength of ones IT unit? We have all seen Parkinson ’ s Law at work in organizations. The law states that work has a tendency to fill up the available time. This means that savings can only be realized where other useless activities do not fill up the space that was previously occupied by superfluous development lines, infrastructure components or the misguided projects!
9. Conclusion: Finding the Right Course
Abstract
According to the current point total, the lively debate that took place in the year 2003 about the purpose and benefits of IT — a debate triggered by Nicholas Carr ’ s article IT Doesn ’ t Matter in the Harvard Business Manager — would seem to have been won by the proponents of the view that IT plays a crucial role in enterprise success.
Backmatter
Metadaten
Titel
From Enterprise Architecture to IT Governance
verfasst von
Klaus D. Niemann
Copyright-Jahr
2006
Verlag
Vieweg
Electronic ISBN
978-3-8348-9011-5
Print ISBN
978-3-8348-0198-2
DOI
https://doi.org/10.1007/978-3-8348-9011-5