Collaborative EA Information Elicitation Method: The IEM for Business Architecture

This study contributes to the enterprise architecture (EA) methodologies by suggesting a method for eliciting architecture requirements: gathering both the current architecture information, and the development needs and requirements for the business architecture (BA) dimension in EA planning. Most of all EA dimensions, the developing of the BA requires collaboration with various non-IT stakeholders. It presents thus challenges to the IT department, or the consultancy involved in EA related efforts. The contribution of the various stakeholder groups as informants is, however, crucial to well founded EA design decisions. The suggested method takes related IS development fields as starting points. Collaborative approaches are well established in the fields of requirements engineering and business process design. However, EA specific issues remain to be explicated and incorporated to the collaboration. A BA information elicitation method (IEM) is not only a tool of the IT professional for a sound foundation for defining of the EA baseline, and developing of the requirements, but also an organizational change management vehicle. Involving stakeholders in a planned, consistent and balanced manner, it supports the establishing of collaboration routines of the IT and business stakeholder groups. The observations in a 12 month EA initiation project in a public organization are a basis for this constructive effort, where a BA elicitation method for the enterprise architecting is created. The constructed method is enhanced by evaluative comments of seven EA-experienced IT professionals.


INTRODUCTION
Enterprise Architecture (EA) is a promising approach for public sector ICT.The renewal of administrations (e-Government and e-Governance) [17], [16] driven by ICT advancements enables besides digitized services, also new, lean and agile organizing and potentially a better informed decision making.Public administration (PA) means usually large, multi-domain organizations, raising the need to collaboration and complexity in organizing.EA has since the 90's been deployed by national governments in their IT function, and getting more attention even at the local administrations, as well as the domains, where public ownership is dominating in many countries (e.g.education or healthcare).For this study, EA is defined as 'a holistic approach to organizational ICT planning, design, development and management'.The aim of the study is to contribute with a method of information elicitation from the ICT user organization for EA, focusing on the organizational or business dimension of the EA.The need for this was triggered by a case project of introducing EA in a public organization.The study is conducted as a constructive research effort.Part of the complete research cycle is evaluation, which in this case is conducted by EA practitioners, whom the preliminary construction, built with theoretical knowledge, is presented.Thereafter, the construction is completed in a second iteration with the evaluation results and comments of the practitioners.
We look into a relatively large organization striving for EA adoption to the enterprise ICT management, by involving also the line organization managers.This large institution, albeit having a degree of autonomy, is ruled by the present andmaybe even more -by the historic PA governance approaches.We see here the potential to adapt knowledge created earlier in the areas of requirements elicitation, and work with business processes (analysis, modeling, re-design), and suggest a simple model that can be followed to capture the essential information on the business for the business architecture descriptions, both as the current state (as-is), and also as the target state descriptions (graphical models, textual and tabular representations).The focus is at the level beyond the general managerial view, i.e. with a deeper insight into the business operations and the detail of the functioning processes and business services.

II. METHODIC APPROACHES TO EA
The elaborations on EA methodologies seem to confirm the consensus of four main dimensions of architectural information to be dealt with: the business, with an emphasis business processes, the information, the systems and applications and the technologies [29].This consensus identified earlier by [11], and later reflected also in the TOGAF [26] Content Metamodel, representing an acknowledged consensus in both theory and practice.The four main architectural dimensions show a high penetration especially in the practical EA methodologies by consultancies.Variations exist, e.g.[29] concedes the business processes as an element of EA, justified by the importance of the business process view to the business architecture and the adoption of the process architecture concept in the business oriented literature as well [15] that stresses the holistic, process network view to the business operations.However, an overall business architecture concept entails other elements like business models, organizational structures and also services.Business processes are accommodated as components of an overall process architecture constituting a part of the BA.
EA methodologies exist in abundance [5], [25], [26], and they seem increasingly to join forces with the line of research on ICT and business alignment [1], [20], [27], that addresses mostly the general managerial, or the 'CxO' level views to the enterprise.This area has been well furnished with methodic approaches and techniques to support the strategic management and enterprise decision making, the IT-business alignment or strategic alignment of IT.An example is applying a portfolio approach in management of both systems & applications and the technological infrastructure and investments.When it comes to the implementation, the methodologies of systems and software development, as well as of project management appear mature on one hand, and on the other an evolving field.Repertoires of methodologies exist and evolve towards e.g.agile approaches.Methodic approach to join the two, the general, strategic managerial supervision, to the systems and software development footwork, would be needed for the promise of the EA benefits to materialize [19].For a real impact, a strategy should be implemented at the level of business operations.The latest version of TOGAF incorporates the segment architecture [26] (a.k.a the architectural domain [19] and [3]).Before elaborating this concept for the current study, the concept of business architecture (BA) is defined.

A. Business architecture
Business Architecture is an acknowledged EA dimension, accounted for in the TOGAF 9.1 ADM (Figure 1), [26].The obvious reason to take the business architecture as the focus of the collaborative work on EA is, compared to the other three main dimensions, that the information needed for BA descriptions and deliverables must mostly be collected from, and co-constructed with the business professionals.
Figure 1 The relevant phases of Togaf ADM Information architecture (IA) also strongly depends on this business related information.However, for the information dimension, the elements of information architecture can be elicited to a large extent from the business descriptions, e.g. the descriptions and models of the business services and processes.However, it is advisable to pay attention to the IA in collecting information for the BA.The collection of business information will further help in completing the application and technology portfolios, given that the business criticality and related risks are accounted for by the business specialists.As the ADM process indicates, the BA is one of the early phases in an EA development effort, constituting the starting point for the development of the further dimensions.The BA information should serve the construction of the other three dimensions (information, systems, and technologies).
Typical elements of BA have been accounted for in several studies, [5], [29], [11], [12], and [19].Especially [5], [11] and [19] further acknowledge three levels of organizational decision making and the need for descriptions with adjusted level of abstraction accordingly.The essential information to be collected on the BA, its current and target state descriptions includes at least following items:

B. Level of business operations
This study focuses on the middle layer of the EA work, concerning the operating business, that is segmented (as the TOGAF Architecture Segmentation suggests [26]) to architectural domains (or segments) within the enterprise.The reason for this is, that the general, enterprise-level guiding principles (mission, vision, main strategic guidance) is decided upon by a small number of people and forwarded as 'a given' for the architecting work.Exchange with ICT experts, for informed strategic decisions aware of technology enablers and opportunities to enhance the business with ICT, should, however, be ensured [19].This usually is undertaken as strategic consulting, that as well can profit from more precise Preliminary -Architecture capability building

Architecture Vision
Business Architecture Requirements information collected and delivered in form of architecture deliverables from the different segments (e.g.core processes, business units) of the enterprise at the level of business operations.The focus of information gathering is therefore at the middle level of the three organizational levels [5].At the bottom level, the practical decisions with IT and IS, should be enabled and supported by the middle level being well covered with information in form of architecture descriptions and models.The third level (in EA terms) means systems work, translating the elicited BA information or business requirements into systems requirements; and, for example, business process descriptions and business operations model into executable process models, with business logic and rules.
The targeted organizational middle layer [5] describes as "mediation between the organization and the immediate task environment", a step down from the strategic management in the scale of abstraction.To pursue collaboration in enterprise architecting in an organization, aims firstly at more accurate information on the business and how it works and the development targets.The second, as important aim is to involve the members of the organization by a participatory approach [12] to voice their views on what and how could be developed.This might be of importance also in gaining the critical mass to adopt an enterprise architecting approach.The participants in the effort should be able to perceive it as a direct way to influence the decisions on designs and developments regarding the ICT solutions in their own daily work.
ICT enables an increasing number of business model developments (cf. the Business Model Navigator by [8]).With this fact, a collaborative design approach to enterprise ICT seems crucial for success of both the business and the IT departments.EA offers itself as a methodic way to collaborate.

III. EA SEGMENTS AND BUSINESS PARTICIPATION
Organizations are at different stages of maturity in their ICT management and enterprise architecting (Ross et al. 2006).Towards achieving maturity, enterprises should have an interaction between their strategy process and the development project portfolio [5], which may be structured to an EA roadmap.However, those organizations still underway to EA maturity, or taking the first steps towards this approach to organizational ICT, have the need to establish the link between strategy and implementation of the ICT enhancements.To make this complex problem manageable, a segmentation of the enterprise according to logical parts of the enterprise, aids in linking the strategies to the level of operations where the actual business value is created in the enterprise operations.Developments at this level accumulate to a better enterprise performance.The management of individual segments is also a prerequisite for managing inter-segment developments and collaboration.
Ensuring broad participation by business stakeholders serves two goals.Firstly, the necessary precision and depth in eliciting the information on the practicalities of the business can be achieved only at this level, when people from business operations are engaged.Not only does this enhance the quality of the architecture deliverables, but also gives an opportunity for the meeting of the business and technology viewpoints, for idea creation towards developing the business through technology enhancements.For precision of the EA work, the managers of business operations and the domain experts are able to provide the details of the structures and organizing, the models of operation, processes, procedures, workflows, services and customers and their significance for the business and linking them to value creation.
Secondly, to succeed in establishing an EA management, sufficient organizational support is needed, a fact known in the change management [14].The organizational IS studies on enterprise systems with scope covering the whole organization have stressed the role of the management as a top influencing factor [24], [8], [7].Though there are scarcely EA-specific CFS studies, recent findings point to the similarity of enterprise system and EA challenges and CFS [22].
In case of enterprise architecting, the change management issue is two-fold.In introducing the EA as an approach to ICT management, combining the business development and the information management activities, is the first stage.The adoption and adaptation of a method for this to an enterprise, requires essentially sponsorship by the top management, however, not only that but also broader support and cooperation [22].As well, when a change is introduced into an organization whether induced by ICT developments of or not, there are known benefits from a "people oriented" [2], or participatory [12] approach.Early and steady involvement for one, and achieving a critical mass for another is essential for an organizational change effort to succeed.When stakeholders are involved who know the business operations, processes and practices more thoroughly the EA efforts benefit as well [11], [12] This is likely as much due to the better informed EA developments, as to the change management aspect and the participation supporting it.
The problem of how to ensure successful elicitation of information for new solution design and development has been a concern in prior work with the business and business requirements.
The participatory IS development methodologies, that [2] calls the people orientation, and the agile movement in software development that stresses the contact with the customer (user).Two specific lines of research have delved into this area.Both are tightly related to EA, especially the work with business architecture: requirements elicitation, and business process design.The work with requirements is essentially a part of EA, as the TOGAF ADM implies: the 'Requirements' deserve a central place as a combining hub in the method cycle (Figure1), with which each method step interacts.

A. Requirements management
No matter how iterative and incremental the chosen methods are, the requirements management is the focal point in involving stakeholders.It may be extended to the whole lifecycle, but even so, with a defined approach the quality of the work (and also the management of the development efforts) is better provided for.Requirements literature offers for the work with the stakeholders of systems and software workable methods and numerous techniques [18], that have been further refined in the long practice in this work.We take on the knowledge on especially the involving, participatory aspect [10] to the constructed method for EA information elicitation.
However, the special requirements of the EA work need to be considered and incorporated for the information elicitation method "IEM".
The model of [10] stands out from the requirements literature for two reasons: it is an outspoken participatory oriented method that stepwise guides the target system stakeholders through the requirements elicitation and development phases of a systems project.A strength of the model by [10] is also that it takes as a starting point an architectural approach, leaning on the six questions also known in EA field, and thus appreciating multiple viewpoints.Enterprise architecting presents specific challenges related to the scope, as the BA elicitation is not dealing with one system only but the whole enterprise.

B. Business process design and management
Dealing with enterprise ICT and systems, an area of work long established is the business process design and management [3][26].For enterprise systems engineering, and also IT services engineering, defining and analyzing business processes is an essential step.BPM makes a direct bridge to enterprise architecting, since the best known feature of business architecture are the business processes, even seen as a separated element [29].For the IEM for BA, the BA elements (see above) follow the levels of abstraction.An equally participatory and thorough method as was the [10] for requirements is the method suggested for BP detection, analysis and definition by [23].This approach also readily incorporates the three abstraction levels, supporting [5] that derived these from organization theories.The model by [23] details the systems work for the further levels, however, this goes into the realm of systems work with an individual IS.For EA this corresponds to the systems level [19], from which the deliverables are handed over to individual systems projects.
The study of established techniques for business process work and requirements work gives a leap ahead in constructing a method for the work with BA and the respective stakeholders.As they are, however, designed for efforts with limited scope managed within one project, the information gathering for EA is intended to serve the whole enterprise ICT management and multiple development projects.Therefore, the IEM is equipped with EA related elements.

C. Elements for the Information Elicitation Method IEM
For brevity, the methods mentioned above are not presented in detail in this paper, but common and useful elements are summarized.Critical for eliciting comprehensive business process information, or business requirements, from a development target area:  The need for a 'charter' from managerial level, giving the effort i) motivation and justification, and ii) sponsorship that accounts e.g. for the working time that needs to be invested.
 Not separate from the above, but worth noting is the scope of the present effort.For EA, which by definition is to cover all of the enterprise, a task at hand must be workable.Breaking down to manageable units enables to involve covering representation of stakeholder groups in these units.Scoping also keeps the working groups feasible.
 Even though for the practical manageability, the BA information is collected by segments, the information is intended for the whole EA work.This includes development programs and multiple projects, potentially crossing organizational boundaries, as well as the whole process architecture.
 Coverage in representation of all relevant stakeholder groups and interest groups.
 Group efforts in workshops, possibly enabled with a virtual team support and other collaboration solutions online and co-located.
 A managed flow of work from presenting the problem area and the charter, to enable everyone to contribute in professionally organized workshops or other similar activities.Opportunity to review the work results and to achieve acceptance of the representations (deliverables) by the stakeholder groups.

A. General Principles
Enterprise architecting is a continued activity to maintain the "striking power" respective to the business environment of the enterprise.An effort targeting to architecture developments, the delivery of an artefact (an implemented architectural element or its modification) relates to a defined context, often demarcating an architectural segment or domain.Architectural planning and design precedes the implementation.The business architecture is often the first development step, followed by the information systems and technology developments.
The TOGAF ADM sees the following generic, iterative steps as common for the work on any of the four architectural dimensions, represented as phases respectively in the ADM:  Select reference models, viewpoints, and tools  Develop Baseline Architecture Description  Develop Target Architecture Description [26] Another trigger for the need to study the business architecture is related to the IT Governance (ITG) generally, and the architecture governance more specifically to guide the management of the ICT assets in the enterprise.As the ITG activities are a responsibility of the IT departments, they need to be instructed with a policy of collecting information on the business (BA) in a manner that ensures coverage and accuracy.This means representative involvement of business stakeholders.
Be it either for a development project within the EA, or for the information management function activities on IT and architecture governance, accurate descriptions of BA are a crucial vehicle for transmitting the requisite information to the IT professionals working on the enterprise ICT and related resources.This idea has been supported early on in the business-IT alignment literature [20].The suggested IEM aims at providing guidance, how to proceed when the concern is EA, not only a single project on process or systems development.

B. Empirical Study and Method Construction
The first part of the empirical study was the observation of a one-year EA project with the target of introducing and deploying an EA approach into an organization of ca.2000 employees.It has seven rather independent organizational units with a common IT department to provision infrastructure, common business systems, maintenance and administration of personal computers or laptops.The project was well resourced, with ca.4,5 work years, and occupied with staff prior knowledge and requisite skills for EA type of work.Following the project board meetings and reports, the project reported a huge amount of contact hours (1000+h) with business representatives, at both executive and business operations management level, in form of presentation sessions or meetings.
Part of the project target was to "involve" business, to ensure that the EA will be business driven.Although a vast resource was consumed, the results, in terms of BA descriptions, were devastating.Deliverables completed within the project were related to mostly the systems or technology architecture.The project team could have constructed these deliverables (e.g.application or technology portfolios) without engaging business representatives.Informal meeting memos from the hours (wasting time of business stakeholders) did not appear contributing to a base of business architecture descriptions, systematic evaluations of the current state, the business priorities etc.The experience in this case shows that without a defined technique, a method or pattern of information collection, time spent in collecting BA information does not automatically render useful deliverables.
In a next step, based on the aforementioned established techniques, a preliminary BA information elicitation method (IEM) was constructed.There are preconditions for BA and business stakeholder involvement.Firstly, there has to be a defined scope for the effort.In large enterprises, that EA the methods mostly concern, all of the BA cannot be covered in one shot, but has to be partitioned (see discussion on segments or domains above).According to the architecture segmentation, (division to domains), the target scope can be delineated, and information collection effort mandated for this area.As the EA itself, also a BA development effort has to be chartered and sponsored by the management, both business and the Information Management function (IT department).This is important, as both have to sponsor the effort: the preparation of deliverables, descriptions with models of processes etc. is normally a capability the IT is providing, whereas the business has to make the necessary roles and their working time available.
A second pre-condition is establishing the ways and means for the retention and management of the BA deliverables.This is an important aspect in the deployment of EA approach organizationally.Most enterprises have an online facility allowing for sharing information accessible to defined user groups (an "intranet" with dedicated databases or collections of data or "workspaces" for specific purposes).Establishing such an EA repository, which can start simple and small, supports the organizational change effort.Later with growing needs, a combination of modeling tool with abiding database management system becomes essential.Firstly, this may mean adopting EA as a method to cope with ICT challenges in organization, and secondly, it concerns the managing of changes undertaken in the organizational ICT.When the EA descriptions, especially BA descriptions, are accessible to anyone whom they may concern, any planned and upcoming ICT developments can be discussed based on them as a common artefact.A common artefact supports explicating issues, negotiation, and creating a common understanding.In this way EA and especially BA will become the tool for business-ICT collaboration as intended.It provides the common platform for the organizational development discourse on ICT related matters.Questions on the collaboration tools are left out of this report due to the limited space.
When the pre-conditions are set, and a BA effort chartered, the respective executive representatives and business stakeholder groups are contacted.The executives give the overview, limitations, and their views on the BA effort.If there is a specific EA or business development target, the executive visions and targets for the development effort are discussed.This may guide the following work.At this point, the relevant stakeholder groups are listed, and recommendations for the representatives of each group to be contacted are asked for.These are the people with whom the workshops are run, and who support in the due diligence of data collection.This may include representatives of the executive level of the target domain area, managers or supervisors of business operations and also people involved the actual activities and tasks constituting different business process steps.Fig. 2 depicts an overview of the method construct based on the EA body of knowledge supported by the related fields of requirements and business process management.EA segmentation is a precondition.
Figure 2 Using this method: "establish the BA area" means that the IT professional creates a preliminary description of the domain within the scope that the effort concerns.This is done both by interviews and the study of possible existing documentation (organization charts, business process or services descriptions, etc., strategy statements).If a repository (descriptions database) exists, refer to it for existing EA descriptions.Decision on the number of stakeholders to be involved, and their positions, is guided by the preliminary work on the domain area.Depending on the number of members to be involved, one or several workshops can be organized.As needed, you can iterate, but pre-limit the number of iterations (to 2-3) to achieve results.The EA repository (which way ever the EA/BA information retention facility is set up) is also introduced to the people involved.Be prepared to that the use of the repository (or just the portal) may need training.

C. Method Evaluation
In the step two of the study, seven professionals working in large organizations in positions of Information Management or IT Services were asked to evaluate the suggested method.Each informant represented a different organization.The questions: 1. Would this method be suitable for enterprise architecting in practice?
2. Do you think that this method could enhance practical EA work and especially information collection for it?
3. Can you point out things that make the method more or less practicable, or suitable for the intended purpose?
4. Does the method lack some essential elements?
5. How could the method be improved?6. Would you deploy this method, or could you recommend its use for enterprise architecting / work with BA?
The answers are summarized in the Table 1.The reception of the suggested method was overall positive.Some informants told it would take some maturity or at least awareness and some improvement.Enhancements to the IEM were proposed.We have included several in the construct presented in this paper and in the concluding remarks.According to the informants, indeed there is a lack of this type of method or pattern for EA information elicitation.Consultancies have each a pattern or method to run this type of work.Essential for successful EA work would however be to own both the work and the resulting deliverables.If (as came out in the answers of one of the respondents) a consultancy conducts the information collection, puts the deliverables into a repository (that the consultant designs), the work results may be left with any further attention.Costly paid, the organization falsely believes to 'have an EA', but in reality nothing changes in the ICT management, or in the line of business -IT collaboration.EA, and specifically the BA deliverables are not created for a project team to be used within a single project, but are constructed for publication and sharing across an enterprise and possibly for external developer teams.This sets different quality targets regarding clarity and comprehensiveness of the descriptions.The business representatives not only in the respective domain, but also at the enterprise level, and to an extent also in other domains, should be able to interpret the descriptions and recognize their own part of the business as a part of a whole, or their interface to the described domain.Developments around ICT may mean also changes in structures and organizing, e.g. in processes.Even the architecture segmentation might need to be revised on need.A base of accurate EA-and BA descriptions gives a reference point for discussion and negotiations around targeted change efforts, and helps avoiding the negative effects of organizational change (inertia).In Fig. 3, an overall flow of work in a workshop, a preferred technique when involving domain experts, is outlined.Considerations that have to be taken into account when the method is deployed include:  The enterprise level (strategic level) decisions and architectural principles should be known and presented as the starting point, to keep the effort aligned and supporting the holistic approach aimed at with EA.
 Templates, lists of questions to ask, and checklists for information completion should be provided.The IT professionals should know what information is relevant for ICT developments to enable the subsequent systems design work.
 Scalability of the method is important, but e.g.workshops do not work with large groups.When architecture partitioning is well taken care of, the method scales as it is deployed segment by segment.Within segment, one or several working groups (WSs) can be accommodated.
 Separation of the current state (baseline) and target state (envisioned BA developments) is important.Whenever people are asked about their work environment, problems tend to surface.It is a good idea to note, that for analysis and new designs, the as-is current state needs to be described [23].At the same time, perceived problems with it are also taken notice of for further considerations.Target state workshops are arranged to leverage business knowledge for ICT developments and to study the opportunities to enhance the business with ICT.
 The BA concept of vs. business processes was discussed.The suggestion to concentrate only on business process modeling could, however, lead to a too narrow work on the BA and is not supported in our method.On the contrary, the broader BA with e.g. business models and services should be taken into account to enable co-creative business development.
 Description and modeling techniques, and languages (of which there are plenty [4]), were discussed.For the method, this is an issue that can be furnished with i) the existing BA descriptions, ii) drafts presented to the business stakeholders for their perusal and iii) a choice of templates.Description techniques, modeling languages and tools remain enterprise internal decisions.Concerning BA the information collection should deploy "user friendly" techniques and templates.
It is recommended to collect the information with structures known to the respective stakeholders and use, e.g. business scenarios.
 The short life-cycle of the descriptions was pointed out.The target of enterprise architecting is not to create a one-off description of the EA "for the shelf" at one point in time, but to serve as the requisite information base enabling the construction of plans and designs and the realization of them.Documentation on EA has value only to the extent it supports activities on the concrete ICT assets and their deployment.We refer to the definition of the target of the information collection effort, and the delineating the scope of the effort: What is needed for enterprise architecting to be followed by concrete developments on organizational ICT.
 For information discovery in order to be able to describe BA, business scenarios may be a supportive phase to reach an understanding sufficient to construct the requisite deliverables for sharing among stakeholders.Scenarios do not require the use of specific notations or modeling languages, but can be translated into required models and descriptions by IT professionals later.
 The EA portal should be an interactive platform.The repository may be in the hands of IT professionals, but the portal should give access to information in easily perceivable forms, and enable inputs (comments, questions, ideas or complaints) from all stakeholders.An interactive platform may spare working time, if e.g.instead of review meetings, the reviews of constructed descriptions on BA can be conducted online via the portal within a given timeframe.
For this type of WS work, some general principles worth noting, supported both by [10], [23] and the comments of the informants of our study are:  An atmosphere of trust and appreciation is created and the input by all contributors is equally appreciated  The contributors are encouraged to share with the WS group all relevant information in their possession  There is a common responsibility of the correctness and completeness of the WS deliverables  All conversation and criticism is on items and issues, not on people.
 The business stakeholders should be able to provide information in formats they are comfortable with.
 All stakeholder groups should be able to contribute and cross-fertilize with knowledge and ideas.
The workshops have also an educational purpose.It is a good chance to present EA and the work with BA as a mutually enriching opportunity for exchange of information, problems and ideas around the enterprise ICT.Workshops can be iterative, and it is recommended, that the participants have a chance for more than one rounds of contributing.It is well known that the best ideas only occur after an event like a workshop, as the thinking processes have been stirred and the ideas have had some time to settle.In any case, the review and approval should be kept separate from the workshop itself.It might also be advisable to involve different people for the reviews, to ensure broader consensus in the domain area, and a better quality of the deliverables.Following concrete EA developments justify and reward the work undertaken.

Figure 3
Figure 3 Running a BA Workshop -main steps