EA Planning, Development and Management Process for Agile Enterprise Development

In this study, we suggest an enterprise architecture (EA) development process model suitable for EA projects limited in scope and time. Several EA process models have been put forward, which have in common the idea of comprehensive EA management and development that is generic, cyclic and ongoing in a user organization. The suggested models are of varying level of abstraction. It is not simple to select the right issues from them for a restricted development effort. An ICT services provider needs a process model to follow in EA consulting and development projects. This approach is also needed for incremental EA development by user organizations. Starting with the suggested EA process models and with findings in IS literature, we create a generic process model for EA management. Based on this model, and supported with a case study, we then develop a process model for discrete EA development efforts undertaken as incremental steps.


Introduction
Information Technology Governance (ITG) [22] and Enterprise Architecture (EA) [32] planning, development and management are focal points in the current discussion on information and communication technologies (ICT) in organizations.Several efforts have been made to create frameworks and methodologies for this work.The earliest of them [20,30] stem from times before the current networking technologies were known or widely used.With the radical changes ICT has brought into organizational activities in the past decade and a half, a lot of work has been done on methodologies for organizational ITG and EA development and management.
In a research project with three ICT provider companies and an academic institute, we have been exploring enterprise architecture methodologies, in order to find a suitable methodical approach for EA related projects of varying size and scope, conducted by a services provider.In this paper, a process model for the methodology is developed.
We first explore existing EA process models (Section 2).Then, (in Section 3) we enrich the paradigm with findings in IS literature, and a more recent approach to EA, an EA management Grid, with the same target as we have for the EA process: incremental stepwise EA development.It can be undertaken as restricted projects that are possibly conducted by a services provider.We then suggest a generic EA process model and derive from it an EA project process model.To validate these, we explore EA projects conducted by a provider (Section 4 and 5).Section 6 provides discussion of the findings and Section 7 concludes the paper.
Requirements have been elicited for a methodology that could be used in discrete EA development projects conducted by an ICT provider [15].From these requirements, the following apply to the EA project process and guide our effort: • The method bridges business consulting to traditional systems development • The transitions from business considerations to architecture development, and further to systems development, should be smooth • The method should also be easily introduced to non-ICT-professionals, since collaboration with clients is essential in this type of projects • The target organizations have different levels of organizational maturity; therefore they cannot be expected to have well defined processes or architectures.The process model should hence be applicable in less mature organizations only starting with their EA planning [28] • The process should be easily adaptable to projects of varying size, scope and focus, covering any set of viewpoints and abstraction levels within the EA area.
A comprehensive process as a guideline for short projects may mean overuse of resources for a minor development step.
• The model should serve as a basis for knowledge sharing and transmitting across expert groups, i.e. it should be comprehensible by both business experts, enterprise architects and software architects.
Additionally, an EA process model suitable for incremental EA development and discrete EA projects should • Make transparent for both the user organization (client) and the provider, what the scope of the development effort is, and which issues are dealt with later in the client organization's EA management process.This is essential in requirements and constraints elicitation, and also helps to avoid conflicts or overlapping efforts in different parts of the enterprise • Guide the development process from project launch activities to the project results review and evaluation, also allowing for definition of quality control points.Today's comprehensive ICT usage in organizations makes the work with EA also work on organization structures [2,22].Additional requirements are therefore crucial for an organization to manage the change: • Limit the change effort in two dimensions: scope and time.
• After a change cycle, free space is required for evaluation and adjustments -also culturally and mentally, before the actual benefits will be visible, and it is reasonable to start a new change cycle.

EA process models from the past to the present
In the following, we give a short characterization of 14 models suggesting an EA process.The scope of the paper does not allow for an in-depth presentation of them.A brief description does not do justice to these efforts, which together form a rich base of knowledge on EA development and management, but for our purpose the basic outline of the process models suffices.
1. NIST EA Model [20] The US National Institute of Standards and Technology EA model was among the first ones to present the different EA viewpoints as architecture levels: business, data, systems and technology (infrastructure) architecture.This model is static and not first presented as a process, but it suggests feedback loops from the bottom to the top, which makes it resemble later EA process models.
2. TOGAF 7 ADM [32, 21] The Open Group Architecture Framework TOGAF is accompanied by an Architecture Development Method (ADM) with an enterprise architecture process model as the core of the method.On the publication of the next one, version 7, it was renamed "Technical Edition" which reflects the emphasis on technology.
3. The Enterprise Unified Process (EUP) is an extension to the Rational Unified Process (RUP).The process is developed from a tool viewpoint, and adds enterprise architecture development to the UML-based software process [1].
4. GIGA EA Process (EMEA), [24] is based on layered architectures, like e.g. the NIST EA model suggests.A linear process is suggested that covers these architecture dimensions.
5. META EA Process is a spiral model with 3 cycles following the general idea of spiral model of software development.[18] 6. CIO Council Practical Guide to FEA [7] The CIO council EA process model is a high level ICT governance process consisting of managerial tasks for the most part.
7. TOGAF 8 ADM [32] is developed from the TOGAF 7 ADM model (see above), to which business alignment aspects have been added in the beginning.For the actual architecture development the process phases remain as in version 7.
8. Enterprise Architecture Process (EAP) [31] is a linear process for a once-for-all EA development effort that takes into account consulting aspects of EA planning work.It is one of the early visionary models, from a time when the networking era was only beginning, some leading organizations were only taking up EA work.9. Enterprise Information Technology Architecture (EITA) planning [3,4] is a model that meets many of the requirements mentioned above: It is applicable also to smaller scale development.We found that it can be communicated also to non-ICT-people.
10. Enterprise Architecture Development by [11] suggests a cyclic process that has solved the business organization -technology parallelity problem with two parallel cycles: redesign of both business and ICT infrastructure at the same time.
11. Process for Zachman framework [23] takes as a starting point the Zachman framework and suggests a topdown process where the order of the framework columns at each level is not pre-defined.The extensiveness of the framework is taken over into the process.
12. Popkin process [25] is a tool-oriented process also based on the Zachman framework with different approaches for different types of projects and various ways to proceed within the framework.This software development oriented process does not include the broader scope of enterprise architecture with organizational (business structures) development.
13. Basic Enterprise Architecture Methodology BEAM [6] This process model resembles the cyclic process of TOGAF 7 and 8 ADM.BEAM is an ensemble of various views of EA and the processes around it consist of many features presented in previous work in the area.
14. EA related organizational processes by Gartner [10,27] does not depict in detail the EA development process, but rather shows the position of the EA development process in a network of managerial processes.Some issues of these other processes are included in other models, like TOGAF 8 ADM or CIO Council model.
There has been a lot of cross-fertilization in the creation of the models.A significant group of these processes have been influenced by the work around the Federal Enterprise Architecture Framework FEA [8]: Not only the rather abstract CIO Council model, but also TOGAF ADM 7 and 8 process models stem directly from these (FEA and the process models included in the frameworks of US Federal Agencies).Also, for example [11], the IBM EA method [26], and [6] have several similar traits.
Complementing these process models created in the context of large organizations and public sector, there are light-weight process models better suited for the private and maybe not so large enterprises [2,3,11].
Tools vendors have created process models supported by a tool: EUP [1] and the Zachman-based Popkin process [25].In both EUP and Popkin, the close relation to software process can be seen.Although the Zachman framework is generally accepted as a meta-framework for the whole EA field, its strengths seem to be more in the representation of the static EA than the EA process dynamics.Another Zachman-based process besides Popkin is presented [23], suggesting a top-down type of process from row to row.
EA management and development is an ongoing process in user organizations, and therefore most models suggest a cyclic process.For incremental development steps, undertaken in projects, we need a more defined idea of the cycles: where the user organization is at when launching an EA development project.Only one of the models suggest a fixed number of cycles [18], but none of the models specifies what exactly will be accomplished with each cycle.
Generally, these models represent the context of EA management and development in user organizations.The case company in this study, an ICT services provider, has not found these models suitable as a guideline for the work with their customers in the EA consulting area.Our first concern is also, to modify the process to suit discrete EA development projects.To fit to this context, the process models should give guidelines for a consultant's work and its quality control.We found that the issues suggested in the process models are of varying levels of abstraction and belong to different management levels.To get a manageable picture of EA, we examined the levels and compared them to existing models.

Levels of decision making as EA management process cycles
We found two IS development approaches that both consider decision making as the crucial issue for taking the next cycle.The hierarchical spiral model of IS implementation [12] and the helical spiral model of cooperative evolutionary system design [17] both define layer by layer which issues are specified, defined and decided.These become constraints for the remaining development process.Both models have similar targets: to make explicit the inputs of different stakeholders in a development effort and to ensure informed decision making at each level.
The idea of a spiral model for a software system life cycle [5] for software engineering has been adapted into an information system development model [12] taking into account the need for intertwined organisation and systems development.The three levels of modelling suggested in the hierarchical spiral model are the organisational, logical (infological and conceptual) and technological level.These aspects are developed, and the decisions made are frozen before going on to a further level.Finally, there are fixed decisions on all aspects of the software to be implemented: the organisational change decisions, information architecture and system concepts, as well as decisions on implementation technology.
To cope with profound organizational change, the aspect of user participation has been added to the spiral model, thus developing a so-called helical spiral model [17,29].This ensures informed user decisions when proceeding from abstract to more concrete issues in the development.
In EA efforts, decision making is a crucial dimension of user participation.User roles, such as the "client" role that emphasizes decision making, have been introduced by [18].When developing EA today, decisions are made not only on simple questions: "to implement or not to implement" or the limits of the budget, but negotiations with decision makers may go to detailed questions of technology and emergent organization with novel business structures and models revolutionizing a business [4].Also, financial questions arise, that are connected to qualities of the technology, e.g.scalability, stability or security.
An EA management and development model called an EA Grid [14] joins architectural dimensions with levels of decision making (that also can be perceived as levels of abstraction) to a compact EA development and management matrix.The level concepts in the hierarchical spiral [12] and e.g.NIST [20] EA models are roughly corresponding to the widely accepted EA components [e.g. 10, 11, 18 , 32]: -Business Architecture (BA) -Information Architecture (IA) -Systems or Applications Architecture (SA/AA) -Technology Architecture.(TA) In the Grid these are not seen as layers, but as vertical dimensions (Table 1) that cross three abstraction levels that correspond to the levels of decision making [14]: -Enterprise level -Domain level -Systems level.The four EA components, or dimensions, are commonly suggested as forming a hierarchy [e.g.24,18,32].The NIST architecture pyramid [20] makes this explicit.However, because of the change in the role of ICT in organizations, it is crucial to have all these dimensions also at the top decision level (Table 1).This, in essence, is different in today compared to the past IS development situation.It used to be possible to make decisions hierarchically, starting with business processes and structures; the technology questions only entered into the decision making when the business and the logical structures were designed and fixed.Today, an approach like the EA Grid is needed: even the top business managers need to participate in discussions on technology issues at enterprise level.Also, risks and cost have to be discussed right at the beginning, there is no longer a set IT budget to start with but with each development step an evaluation of benefits is also undertaken.
The original idea of the spiral model of software development was to alleviate the effects of hierarchical decisions.We suggest taking the spiral concept for EA development process by bringing all four dimensions to the top/enterprise level, and going down to domain and systems levels, where decisions covering these scopes are delineated.The user organisation involvment suggested in the helical spiral model [29] is essential, since in an EA project, collaboration and a joint decision making process with business and IT managers is needed.
The spiral model sectors cannot be taken directly from the software development or prototyping spiral.META EA process [18] has defined the sectors, but does not specify the criteria for moving to a further level.The EA planning and development Grid has the basic idea that at each of the levels, decisions are made with a scope wider than the one(s) underneath, thus forming a continuum of decisions that become more and more focused, concrete and detailed.At the enterprise level, general strategies, guidelines and policies for the four architectural dimensions are set that are to be followed in the whole enterprise.At the domain level, the enterprise level decisions are taken as given and further decisions are made for the scope of the domain.The domain in this case may mean a business unit, a business process [32], or a group of processes, a service or other defined area with some shared information and systems so that it is reasonable to bundle it for one development effort.Additionally, domain level decisions are part of the requirements and constraints for the systems level, the planning and refinement of decisions that cover the systems in use in the defined development scope.At the systems level, business requirements are refined, information architecture modified to detailed data architectures and application patterns and principles as well as technology implementation are outlined.
The EA Grid [14] based EA planning and development process (Figure 1) takes into consideration all four architectural dimensions (BA, IA, SA/AA TA) and their evaluation [13] within each cycle.Types of decisions made at the levels are presented in the Grid (Table 1).From the point of view of a user organization the EA process is a spiral that starts at the enterprise level and goes through the domain and the systems levels (Figure 1), thus getting all the required decisions from different levels for any implementation.This means e.g.new business models, business processes; the information (e.g.considering value-adding information or business intelligence questions and the like); further, applications portfolio and systems architecture decisions; and finally, decisions on the technologies to support them.In terms of the hierarchical spiral model [12] these are: administrative, infological and technology decisions.But important is that here these are considered at every level, with a narrowing scope and lower level of abstraction when going down the levels.
Having this macro-level EA management process, we can go on to define a generic EA project process model.The following course of action is suggested for discrete EA projects: 1. Initiation For a single development effort (a project) the process starts by project initiation considerations.These are: • Defining the target: the improvements / benefits for business performance and enterprise information management that are pursued • Structuring these improvements analytically against the Grid and with the help of it, defining where change is needed to achieve the improvement: at which level, concerning which dimensions? • Identifying with the help of the Grid which issues are pre-defined, i.e. for them no change is desired or planned (any issue concerning any of the EA dimensions BA, IA, AA/SA and TA).These will be the constraints of the development effort from the beginning on.The general constraints: time and resources, are compared with the targets and a refined project plan is made.Depending on the target level and area of the effort, the enterprise level inputs for different EA dimensions are either taken as given (they may have been developed in a preceding effort) or are createdsometimes only for the dimension in the focus of the present development effort, or for several dimensions.The development effort takes place either for the whole enterprise, for a chosen, defined domain in it (e.g. a business unit, a business process or service), or only for the systems in the given project scope.Also, there are projects with a narrow focus.For example, business architecture and the logical structures (IA and AA) are designed, and only technology development takes place.An iterative approach is taken between the dimensions.
3. In the Ending phase, the project results that are plans, designs of architectures and solutions, alternative designs and their evaluations, and development roadmaps are created.Long and short term development targets are prioritized and a project roadmap with schedules and project dependencies is created.With enterprise level planning, the EA management process for the client organization may also be defined and future check points defined for update and further development.

Figure 1 An EA management process based on the EA Grid
Thus an EA project can be followed by a system development project or a cluster of projects of different types: integration of systems, implementing an architecture and / or business process.

Case Study
To test the process model, 7 EA projects are studied.(A similar study can be found in [14], but with only the project results presented in the EA Grid).With data collected in interviews with consultants responsible for the projects and project documentation, we reconstruct the project process in the 7 cases and illustrate it in the Grid (Figure 2, See beginning of Section 5 for explanations).
The projects were chosen by the consultants (with an agreement of the client), they were asked to describe 'typical EA consulting cases'.In all cases, in the beginning phase, the project plan was negotiated including the scope and time, and the problem presented by the client was studied to find out where to start.At the end, the project results were summarised and presented to the client for further action.Generally, the results included plans, suggested architectures and technologies, evaluation results, and roadmaps.In our data, we only present the EA planning or development phases of the projects (Section 5).
The interviews took place in January 2004 and were conducted as unstructured to semi-structured interviews [33,9] Along with the interviews, project documentation for the cases was viewed.Project documents were also used as data [16].For cases I-V, some documentation illustrating the central phases and results of the project was also left with the researchers, but for cases VI and VII it was only possible to view it during the interview session.For all the cases, we could build a common understanding on the course of the process.Limitation of the study is that all cases were conducted by one provider in one country (Finland).
The company in our study is one of the top five ICT providers in Europe.Because EA projects deal with strategic issues, much of the information on the cases is confidential.There are both public sector and private organization clients, and the cases have taken place in the timeframe 2001-2004.Case sizes vary between 30-400 work days.

Analysis
In Figure 2, we present the collected data on the EA projects.Case numbers are I-VII, the columns are BA=Business Architecture, IA= Information Architecture, AA=Application Architecture, TA=Technology Architecture, The rows are: E= Enterprise level, D= Domain level, S = Systems level.The process is presented with sequential numbering of project activities taking place at one of the levels and within one of the dimensions of the EA Grid.

Case I
The client is in a post-merger situation with a need to re-organize information management.A review of the application portfolio to omit overlaps, with a focus on business-critical systems, system life-cycle expectation and information architecture etc. is made, a stakeholder analysis is made and networking needs (both logical structures and enabling technologies) are surveyed.

Case II
The client has well-defined business processes and is considering new systems in a specified domain for customer management and product data management as well as business intelligence and eservices to their customers.Information architecture and application architecture are developed, and technology decisions are made both for the whole enterprise and for the domain.

Case III
The client is in a situation where a monolithic business-critical system needs to be phased out and replaced with new systems (with a better maintainable design and new more up-to-date requirements for interoperability and connectivity).Application architecture is first surveyed (1), follow by an information architecture development (2).Business requirements are elicited (3).A decision on a combination of new systems and the systems architecture is reached (4), followed by preliminary definition of data groups for further database design (5), component architecture (6), a business glossary (7) and finally the application architecture (9) with both logical and technical parts.

Case IV
In this case, the consultant is trusted with enterprise level decisions on EA: the business architecture is surveyed (1) to serve as the basis for decisions on an application portfolio (2) and technology standards and guidelines for the whole enterprise (3).Application patterns (4) and systems level technology policies (5) are defined for systems design to ensure consistent use of technologies and application interoperability within the whole enterprise In cases III and IV, in some dimensions, some of the work was continued at the systems level in a more detailed manner.In case I, information architecture was planned also at domain level.
5.5 Case V The task was to design and evaluate an enterprise wide technology platform.The business requirements were elicited and prioritized, and based on these, platform technologies were evaluated.
5.6 Case VI Although the client came asking for a network solution, it was agreed that business architecture, and the potential to enhance the business activities with the planned network were surveyed.Business architecture planning and definition of the domains, the development continued for one of the domains where the information architecture and systems architecture were designed, as well as the integration architecture at both enterprise and domain level.Part of the work was thus done at enterprise level, and for the chosen domain it went on with more detailed decisions for the domain.

Case VII
The case was a development of a prototype of a new service.First, the business context as a whole was surveyed.For the domain defined in this effort, an application and technology architecture was developed.The information architecture was not specifically focused on, but was created as a byproduct of the application architecture.
In the interviews, we also found out that if the planning or development took place at domain or systems level, the enterprise (and domain) level decisions on at least the BA dimension were taken as given.If the development level BA was not touched, it was also taken as given.The upper level decisions, and BA at the level of the planning, were considered as required preliminaries for further EA development.The projects concerned mostly one or two of the decision making levels, in our cases never all three of them.
Problems occurred if there were no clear enterprise level and/or business architecture decisions, and the consultant's assignment had been defined as concerning a lower level, or technology only.This often meant extra work (the EA level issues and business requirements needed to be sorted out, and a business architecture defined to base the development on).Also, efforts to explain the client EA management issues were taken.In the first four cases, the process seems to go back and forth (iterate) within the logical order of the Grid.
The spiral models often include risk analysis at each cycle.The EA Grid based cycle takes a more analytical view of risk identification: for each EA dimension, the risks are analyzed at each level.The strategic concerns of the enterprise level take into account (in information, applications and technology reviews) both risks and opportunities.In evaluation efforts, analysis tools specific for level and dimension can be used [13].

Discussion
We outlined an EA management and development process based on prior studies on decision making in IS [12], and EA questions [14].The cases explored in our study seem to support the idea of hierarchical decision making suggested in these models.Although none of the studied projects took the full course through all dimensions and levels of the EA Grid (Business, Information, Applications and Technology architecture, at enterprise, domain and systems levels), the preconditions for starting the development effort was that there were decisions made and documentation available about the issues at upper levels.If this was not the case, the project ran into problems: the consultants and architects found it difficult to design domain or systems level solutions if the larger context was not defined.It is hard to tell if an effort means really developing, meaning 'for the better', if the enterprise level goals, strategies and technology guidelines and policies are not clear.It has been possible in the era of stovepipe applications to make these decisions with a hierarchy of the dimensions: first the business administration decisions and logical structures, then only the technology implementation.Yet with today's requirements: information exchange and accessibility across enterprise and interoperability of systems, and new organizational forms and business models enabled with technologies, the development context has to be defined before any architecture or solution can be justified.The so-called "strategic information system" seems no longer possible but the focus is shifting to strategic management of the ICT assets comprehensively.This is what the EA management process is for.Our suggested EA process (Figure 1) covers the macro level development going through all decision making levels (enterprise, domain and systems) and reviewing all EA dimensions (BA, IA, AA/SA and TA) at each level.A discrete EA project conducted by a provider, or undertaken as incremental development of the EA by the organization itself, needs to be placed in this macro level cycle.This is clear from the cases studied.If the precedent issues in the macro level process are not clarified prior to the effort, they have to be clarified, which means extra work for the project.

Conclusions
We have acknowledged significant work that has been done on EA frameworks, processes and methodologies resulting in a rich inventory of models with a variety of elements, and a good basis for a common understanding of an organizational enterprise planning, development and management process.Yet we have found that the suggested EA process models represent different abstraction levels, and suggest mostly a cyclic approach, without any explicit definition of the cycles.
We see that the developments in the ICT field during the past decade have lead to a need to change the way of managing EA.Models created 20+ years ago suggest proceeding from business architecture and logical designs in a linear way to technology and infrastructure designs.Suggested cyclic EA process models repeat this in cycles.Yet today, a CEO considering business strategies and visions needs also to consider today's business and technology environment, possibilities the present and emerging technologies give not only to redesign business processes, but to go over to different organizational forms, business models (e-or mbusiness) and integrate external stakeholders' systems to the enterprise systems.Information is a strategic valueadding asset both to a company and its customers, and not only single systems, but the whole application portfolio is a strategic asset.This is why all EA planning dimensions including information, applications and technology should be present starting at the top level.
With our study, we contribute an EA process model that defines three main cycles going through organizational decision-making levels.Looking at the hierarchical spiral model of IS development, and a suggested Grid for EA planning, development and management, we learn that the key to defining the scope of a development effort is firstly, to define the abstraction level, represented by different stakeholders, who make decisions on ICT assets at different levels in an enterprise.Both models consist of three levels of abstraction / decision making that we put as follows: • Enterprise level (Strategic management, business managers and CIO) • Domain level (Unit mangers or line managers, business process owners; IT Architects) • Systems level (System owners, IT and System Architects) Secondly, EA is commonly seen as consisting of four main dimensions or architectures.At each of the levels mentioned above, plans and decisions are made for the EA dealing with these four dimensions: • Business Architecture • Information Architecture • Applications (or Systems) Architecture • Technology Architecture.The three levels and four dimensions give a compact and comprehensible tool for EA planning, development and management, which can be shared by the stakeholders.Using this 3x4 matrix, we get a three-cycle spiral model of EA management process (Figure 1).The process owner is the user organization's top management.Discrete development projects mostly take place at only one of the three levels, but always need inputs from the upper levels.The focus of the development effort may be on one or several of the EA dimensions.For incremental development steps, the process has three basic phases: 1) project initiation, where the project level and scope is defined, 2) the actual EA planning and development at the defined level, with possibly a given focus: one or more EA dimensions and possibly iteration between dimensions, and 3) project ending phase where the results are summarized, and risks as well as benefits evaluated.
Our findings with 7 EA planning and development cases seem to support this idea: decisions for all dimensions are first outlined as general guidelines and strategies at enterprise level, then for the development domain and last, for the actual systems, including infrastructure, at a detailed level.Also, compared to the requirements for an EA method (See Section 1), this approach seems to be the right way, since it gives the possibility to define the level and scope.
If the user organization has a program to manage their EA that follows this process, discrete EA development projects will avoid problems in defining the target.We could also think that this will mean savings in resources spent on a project, since there is material to start with: business, information, applications and technology strategies and visions guide the EA development work, and if the development takes place at a lower level, enterprise level decisions can be taken as a given starting point.With no defined EA decisions for the enterprise (or domain) level, extra work has to be done, or the outcome of the development effort is uncertain: if enterprise level issues for different EA dimensions like business and information strategies, application portfolio evaluation, and technology policies and guidelines have not been considered and decisions and plans for their aligned development in the whole enterprise made, simply putting a solution into place for a domain means building on sand.