From Enterprise Architecture to IT Governance (eBook)

As the Managing Director of act! consulting GmbH, Klaus D. Niemann specializes in the development of enterprise architectures. IT efficiency and effectivity have been the focus of his more than 20 years of firsthand experience in the area of IT architecture management.

Preface 6
Table of Contents 10
1 Introduction: When Things Just Work 13
1.1 Overview: The Essence in a Nutshell 14
1.2 Orientation: Notes for the Reader 23
2 Foundations: Finding the Starting Point 25
2.1 Enterprise Architecture (EA) 25
2.2 IT Architecture 33
2.3 Architecture Management 34
2.4 The IT Architect 36
2.5 Corporate Governance 38
2.6 IT Governance 39
2.7 Enterprise Architecture as a Basis for IT Governance 41
2.8 Establishing and Using Enterprise Architecture 48
2.9 Enterprise Architecture in an IT Management Framework 50
3 Goals: Doing the Right Things Right 55
3.1 The Potential Benefits of Enterprise Architecture 56
3.2 Optimizing IT Efficiency 61
3.3 Optimizing IT Effectiveness 69
3.4 Optimizing IT Security 78
3.5 The Goal: Illuminate the Dark 84
4 Documentation: Structuring Enterprise Architecture 87
4.1 Anatomy of an Enterprise Architecture Model 88
4.2 Business Architecture 98
4.3 Software Architecture 106
4.4 Systems Architecture 118
4.5 Applications Environment 127
5 Analysis: Evaluating Enterprise Architecture 135
5.1 Overview of Analysis Procedures 135
5.2 Analysis of Dependencies 141
5.3 Coverage Analysis 142
5.4 Analysis of the Interfaces 143
5.5 Analysis of Heterogeneity 145
5.6 Analysis of Complexity 150
5.7 Analysis of Conformity 151
5.8 Analysis of the Costs 154
5.9 Analysis of the Benefits 156
6 Planning: Creating Enterprise Architecture 165
6.1 IT Development Planning 165
6.2 Administering Enterprise Architecture 169
6.3 Developing Planning Scenarios 171
6.4 Evaluating Planning Scenarios 174
6.5 Planning Development Measures 178
7 Implementation: Developing Enterprise Architecture 179
7.1 Translating Strategy into Operational Reality 179
7.2 Establishing Strategic Architecture Management 182
7.3 Establishing Operational Architecture Management 184
7.4 Establishing an Organization 189
7.5 The Costs of an Enterprise Architecture 196
7.6 The Benefits of Enterprise Architecture 198
7.7 Resources: Frameworks and Tools 201
8 Safeguarding: Controlling Enterprise Architecture Development 207
8.1 Processes 209
8.2 Boards 215
8.3 Measurement Procedures 217
9 Conclusion: Finding the Right Course 223
10 References 231
11 Figures 237
12 Index 241

6 Planning: Creating Enterprise (S. 153-154)

Architecture Architecture takes place between two ears.

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?

IT Development Planning

Development planning may have a technical and/or business orientation, i.e. it may concern the infrastructure landscape and/or the applications environment. In either case, development planning represents a necessary extension of traditional portfolio management whenever its goal is not only to optimally satisfy the requirements of your clients, but also to plow ones own field, i.e. to establish the future security and stability of the current applications portfolio.

Development planning integrates the planning of new projects with the optimization of existing systems, the securing of stability and integration, the closing of gaps, the elimination of redundancies and breaches. The outstanding significance of development planning arises from the elimination of unnecessary heterogeneity and the standardization of infrastructure and application systems. The fact that heterogeneous infrastructure landscapes possess a high degree of complexity and thereby generate high costs has long since been recognized.

The heterogeneity of applications environments always comes up for consideration when it comes to eliminating clearly redundant applications in the context of mergers and acquisitions. But have you ever taken a look at your applications environment independently of such external factors and asked yourself whether it really has to be so complicated? Let’s consider an example from the insurance industry: The classic back office systems for inventory management are being developed on a mainframe in COBOL, the sales systems for mobile sales in C++, and the systems for stationary sales via sales partners in Smalltalk.

What is more, the premium calculators on the Internet have an HTML format, while the C++ computing kernels are linked via Java Servlets. The new website has been realized by an external supplier in .NET technology and responsibility for its maintenance is currently being transferred to internal employees. The new generation of inventory management is to be developed in J2EE technology, which is currently being implemented in a pilot project known as PartnerSystem.

Our scenario involves no less than six different technologies that are not a matter of programming languages, but of complete development lines, each with its own programming conventions, tools for version maintenance, testing, debugging, and perhaps even for applications analysis. Each line requires support, each requires specialists and each a human resources development program. And all of the lines will have to be technically integrated with one another. Does this come across to you as an exaggeration or a description of other people’s problems? If yes, then skip ahead to the discussion of the significance of development planning in the context of restructuring projects and standard software development.