# Architecting the Firm - Coherency and Consistency in Managing the Enterprise

Patrick Turner, John Gøtze, Peter Bernus

► To cite this version:

Patrick Turner, John Gøtze, Peter Bernus. Architecting the Firm - Coherency and Consistency in Managing the Enterprise. IFIP TC 5 International Conference on Enterprise Architecture, Integration and Interoperability (EAI2N) / Held as Part of World Computer Congress (WCC), Sep 2010, Brisbane, Australia. pp.1-10, 10.1007/978-3-642-15509-3_1 . hal-01061791

HAL Id: hal-01061791

https://inria.hal.science/hal-01061791

Submitted on 8 Sep 2014

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Architecting the Firm – Coherency and Consistency in Managing the Enterprise<fnref n="1" />

Patrick Turner, John Gøtze, Peter Bernus

ASPL, Brisbane & CEARM, Griffith University, AU
Patrick.Turner@aspl.net.au & P.Turner@griffith.edu.au
Copenhagen Business School & IT-Univ Copenhagen, DK john@gotzespace.dk
CEARM, Griffith University, AU P.Bernus@griffith.edu.au

**Abstract** Traditional Enterprise Architecture (EA) practice lacks a clear and effective governance and management layer that is easily understandable and intuitive to senior decision makers with the modern organisation. This paper uses three case studies to demonstrate the relative maturity of different EA practice groups within these organisations to demonstrate the strengths and weaknesses of a traditional ICT management approach versus those that include EA practice in all levels and domains of management. Concepts of Coherency Management and Pervasiveness will be used to explain the idea of a next Generation of EA practice that permeates all layers of the organisation and no longer remains the domain of technologists but instead influences and informs decision-making at all levels (operational, tactical, managerial / strategic) of the organisation. Conditions of such future EA practices are also discussed.

**Keywords** Next Generation Enterprise Architecture, Coherency Management, Enterprise Architecture Maturity, Interoperability

## 1. Introduction

Enterprise Architecture (EA) as a discipline was originally developed to support the full gamut of management in organisations [1, p23] [6]. However, historically, the architecture function has only been implemented to various extents within organisations, predominantly in technology support roles or as an ICT management framework. This paper presents three case studies (with the identities of the involved organisations removed) to demonstrate different levels of maturity at which enterprise architecture and enterprise architects function in the modern organisation.

Whilst the case studies are not exhaustive, all three authors have repeatedly experienced similar patterns in other Organisations and, as such, argue that the cases can be considered archetypes of the way in which EA practice evolves. The paper argues that this evolution eventually leads to a new approach where the Architecture function is directly responsible to the senior management team and accountable for

<footnote n="1">¹ A previous version of this paper appeared in R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 162–171</footnote>
the quality, consistency and timeliness of the information flow to that group. The direction of the evolution of EA practice (and of its components) points to a future where this practice becomes pervasive across the organisation, is supported by adequate decision support tools, and is the platform underlying the coherency of management decisions [5].

## 2. Case Study Organisation #1 (Local Government Department) Architecture as a Liability (Cost)

Organisation #1 is a classic Government Department. All Information and Communication Technology (ICT) related matters reside with the Manager of the Information Services Branch (ISB). The ISB Manager represented his employees and IT for that matter at the weekly and monthly management team meetings and dealt with all related issues personally. As serious issues emerged (system upgrades, failure of services, production outages, requests for new functionality, security policy reviews etc) he assigned tasks to his senior engineers as necessary. These senior engineers may or may not have been called architects and were often called system support officers, analysts or engineers. They maintained informal networks across the Organisation, based on their reputation and the quality of their work on previous tasks. They had no formal linkages or relationships with operational staff and certainly had no visibility or relationship with other Branch Managers or Department Heads apart from that of an employee delivering a service.

<figure><img src="image_2.png" /><figcaption>Fig.1. Architecture as a Cost Centre</figcaption></figure>

The lesson from this case is that the stage of EA practice in such an organisation is characterised by a 'struggle for existence'. Engineers or Managers trying to establish Architecture practice within an Organisation at this level of EA maturity can find themselves under attack or viewed with deep suspicion or accused of 'empire building' by their colleagues. The level of engagement by non-technical personnel will often be effectively nil and individuals not used to communicating in a non
technical way may find the going too tough and give up. This will often reflect their relatively low standing within the Organisation and lack of real political and cultural power which impacts upon their ability to drive home real and lasting change. Successful individuals working at this level of maturity within the Organisation will often have to adopt a 'crash or crash through' approach to the use of EA and success will largely be localised in the first instance and more a factor of the strength of their personal convictions rather than any commitment to EA at an Organisational level.

Given the above, it can be said that EA within this environment often emerges in the form of a champion or a senior engineer frustrated with the ad-hoc nature of things or someone who has external reading, study or work experience which demonstrates to them that there is a better way of organising and managing an ICT environment. Often this individual goes to extraordinary lengths, with some personal and professional risk involved, to get the ISB Manager to make the first faltering steps towards the development of an EA framework. The EA framework itself will always be seen here as an IT controlled asset, run by 'techies' for 'techies' with limited use and value by other personnel in the organisation apart from operational and program level reporting, specifically for technology driven initiatives or programs of work.

Within this model there is no thought to exposing others outside of the IT Branch to the potential value or utility of an EA framework. Line Managers 'procure' technical resources via discussions with the ISB Manager and expect that they come equipped with their own approach and frameworks that will deliver the required outcomes.

## 3. Case Study Organisation #2 (Large Mining Company) –
Architecture as an Asset

Within this model, the Organisation from the beginning has recognised the existence of Architecture and the potential role it can play in managing and coordinating the delivery of technology aligned programs of work. In this case the CIO has created specific Architect roles (Chief Architect, Solution, Information, Infrastructure architect, etc) with the express purpose of achieving productivity improvements in the management and coordination of large enterprise ICT assets (ERP, billing, invoices, customer and vendor management, payroll, management and operational reporting, manufacturing, logistics, supply chain). In this type of Organisation, there is recognition at least of the potential for EA to help manage ICT assets across the Organisation and the understanding that other Departmental Heads and personnel need to understand and be involved in EA activities within the Organisation.

This stage of EA practice evolution can often be 'evangelical', whereby a defined sub-group or community within the Organisation seeks to spread or extend its influence using whatever means possible. There is a religiosity about 'spreading the word' in that practitioners seek new converts wherever they may find them. The founding of this new faith can only occur because at least one of the senior Managers, often the CIO, is already a convert and the community has at last found some protection within one individual at a senior management level to defend and protect their flock. Architecture is now a recognised practice within the Organisation with
published position descriptions and with proscribed review and over-watch
responsibilities within the design and delivery of any large program of work. Figure 1
illustrates how large programs of work, with dedicated long term program resources
and responsibility for delivering Organisational artefacts spanning several operational
areas (Departments) have emerged.

The locus of control for the EA framework still firmly resides with the CIO and the traditional IT Department aided by an evolved structure hierarchy of chief- or principal architect and then senior and junior architects perhaps also managed by functional layers – i.e. data, integration, system, application etc. Certifications, training and experience with various EA frameworks have now become highly valued and the Architectural community that has emerged is often characterised by religious ‘wars’ between competing ideologies or camps supporting one EA framework or tool-set over another. These often occur within the IT Department itself and can result in significant personal and professional loss of face to the protagonists who often begin to use external materials, vendor publications, industry surveys, reports, consultants, academic or commercial journals to state their case or overcome their opponents.

<figure><img src="image_3.png" /><figcaption>Fig.2. Architecture as an Asset</figcaption></figure>

In this stage EA practice is seen as an enabler for the organisation to define and to deliver ICT services to best support business needs, and architecture descriptions are to be also seen by non-IT people – although traditional models which satisfy IT stakeholder concerns may not be of interest to the non-IT stakeholder [7]. New communication and modelling skills (and tools) become necessary for this more extended architecture practice to be successful. Ross *et al* [9] describe roadmaps and criteria for success for this stage of development with skill extensions and dual role definitions required for Technologists and Managers alike.
### 3. Case Study Organisation #3 (Global Bank) –
Architecture as a Service

On this level of maturity, the EA function is now offered as a core Service provided by a de-centralised Enterprise Architecture team. Not all members of the team are physically co-located, with the delivery and maintenance of core EA assets across multiple geographic locations. Many architect- and analyst roles now reside permanently within business units themselves outside of this core EA team. The core EA team ‘own’ the dissemination and communication of corporate standards, governance and procurement of new system domains and de-commissioning of old core platforms, whole of Enterprise initiatives and upgrades to the core operating systems within the Organisation as a whole but in an increasingly “custodial” fashion only. The first elements of self absorbed “coherency” practice with a level of pervasiveness (unconscious adoption) can now be seen. In organisations with this level of EA practice maturity the core EA team (‘Global EA Framework and Service Delivery Team’ in Fig.3) will focus on strategic initiatives. Also, individual line Departments will now have the delegated authority to design, procure, implement and support their own specialised applications as long as each step in the journey stays within the approved governance procedures and standards and policies.

No longer does the core team ‘own’ architecture outside of the core EA assets and framework, as applied architecture in the form of application and system level design has now permeated the whole Organisation with dozens if not hundreds of simultaneous programs of work occurring across multiple specialised domains of work. The Core EA team is responsible for the establishment of Meta models and a Meta framework, and for a repository and tool-set used for the creation and dissemination of architecture artefacts (architecture descriptions and models), as well as ensuring broad conformity within a published set of standards and procedures. Pervasiveness or “unconscious adoption” is now vitally important if the EA framework is to have any hope of success given the limited ability of the now vastly reduced core EA team in directly influencing all of the architectural and general business decision making events happening every second and minute of the day at all levels of what is now a significantly complex Organisation with many moving parts and increasingly complex decision making points at all levels of the structure.
<figure><img src="image_4.png" /><figcaption>Fig.3. Architecture as a Service</figcaption></figure>

4. Next Generation EA – Architecture as a pervasive management decision support tool

The proposed approach envisages the fully evolved next generation EA practice operating above and beyond the scope covered by the discussed case studies. In this idealised state, the next-gen EA is all pervasive and fully coherent at all levels of the Organisation, a natural and unconscious extension of normal management practice.

Political and cultural divides between technology and business disappear as the management value of EA is realised by all stakeholders and championed by senior managers in making strategic business decisions. A fully pervasive and conformed EA practice and supporting framework across all levels of the Organisation allow for superior and consistent decision-making ability in a fully informed information environment. The underlying framework allows for a fast and truly evolved combination of business and technology metrics and inputs across the organisation. Under this model, the Architecture team is aligned directly with the executive management team and truly accountably for the accuracy, consistency, timeliness and quality of all management and corporate reporting and analysis being conducted.
<figure><img src="image_5.png" /><figcaption>**Fig.4.** A pervasive EA practice supporting coherency in management</figcaption></figure>

As Fig.4 illustrates, the EA team is now involved in producing key issues- and strategic briefing papers for Board meetings and quarterly AGMs. All executive, corporate and management reporting uses an organisation-wide management reporting tool with corporate Dashboards and views available for executive managers and Board members. These reports are now also for the first time fully consistent and aligned with all subordinate reporting layers so that a coherent and pervasive view of the Organisation emerges for all levels of operations and at all times.

The EA team is now fully tasked with the responsibility and accountability of ensuring that all of the technical impacts and technological risks associated with any new corporate initiatives (mergers, takeovers, acquisitions, major system upgrades or business transformation projects) are fully understood and have been factored in as part of the full decision making process for the Board. This responsibility then flows down to ensuring that sophisticated analytics and impact assessments (including scenario analysis and portfolio and program management options) are also available in a consistent manner for executive, senior and operational management teams.

In this role, the EA team (as opposed to operational architects such as solution- or process architects embedded in line Departments and project teams) are still responsible for the EA framework and meta models within the Organisation, but now have the additional responsibility (similar now to that of the Finance function) of ensuring that senior business decision-makers are fully informed prior to any strategic business decision is made. This vision for EA however relies on all of the
technological advances that are part of the next generation vision. Fully enabled and
seamless interoperability across internal business units and external partners, fully
maximised and intelligent pro-active optimisation of existing assets (internally and
externally), use of virtual resources such as cloud- and grid computing and the
creation of virtual enterprises able to react and respond rapidly and quickly to new
business opportunities and threats.

The legitimacy of this new vision for EA is dependent upon some significant
progress that must occur for EA practice and tools to realize this ambition. Elements
needed to implement a fully coherent and understandable framework include:

1. A unifying theory of EA that is acceptable (and accepted) as a common ground by both the business / management and engineering communities. Part of the is technical (need improved tool-sets, metamodels, reference models, demonstrations, prototypes, etc); and part of it is community building to bring together influential thinkers of management and engineering representing both points of view, and to develop trust and acceptance of any technical results;

2. Reliable and effective enterprise layers that seamlessly allow transactional and other information flows through the various domains and sub-domains as well as layers of management. Given today's decision support tools and investment in their deployment, work on the interoperability of such tools is imperative or the above ideas may not be realistic or feasible;

3. Extension of enterprise modelling tools enabling decision optimisation using relevant views for senior management and allowing business prototyping, what-if- and predictive analyses (future state modelling for risk, profitability, cost, resource, productivity and other non financial metrics (e.g. legal));

While the above list addresses several key technical issues and some aspects of
discipline development, coherency in management has a number of other conditions
as well. The summary of these conditions is provided in Fig.5. [5]

There are a number of important consequences to this condition [5]. Firstly, agreed, consistent and institutionalised EA methods create *alignment* between various lines of business which facilitates communication and agreement. Secondly, coherent and pervasive decision making practices allow the enterprise to identify, and to react to, market opportunities, i.e. act in an *agile* way, because EA practice ensures the swift translation of strategic decisions to tactical and operational levels. Thirdly, the ability of decision makers to access the right information in the right time is an *assurance* that decision making will be based on the best available information.
<figure><img src="image_6.png" /><figcaption>**Fig 5.** The meaning of coherency in management [5] (used with permission)</figcaption></figure>

The presented case studies reinforce the findings of others [5] that there exist various maturity levels in EA practice, i.e., even if all the technical conditions were satisfied, for any enterprise the adoption of a pervasive fully mature EA practice needs to go through stages. Doucet *et al* [5] introduce the concept of modes of EA to describe the maturing EA practice. The first mode is called Foundational Architecture corresponds to our Case Study #1 and #2, in which EA is very IT-centric and its tools and methods are used for the optimisation and governance of the enterprise's IT systems, with different degrees of visibility and participation from business. The next mode is Extended Architecture which corresponds to our Case Study #3, where EA is used for the planning of business objectives, processes, etc – not only the IT systems themselves, and with the full participation in an explicit EA process by various business stakeholders. However, on this level the EA process is not pervasive, it is not embedded in the normal processes and as such parts of the enterprise may remain isolated from this practice (such as, for example, senior management). Embedded Architecture is the third mode, where EA practices are pervasive and cover all levels of management, as illustrated in Fig.4. [5] also defines a fourth mode (fifth maturity level) called Balanced Architecture, where the business is actively using EA tools and methods for the creation or validation of business strategies, e.g. to respond to market opportunities in an agile way, to optimise business plans, to analyse and mitigate risks – in other words this is the level where applied EA theory and management theory become indistinguishable. As the Synopsis of the Handbook on Enterprise Architecture [1] predicts “what earlier seemed to be separate disciplines, such as enterprise engineering, systems and software engineering, project management, and industrial and manufacturing engineering, suddenly become unified into one under one powerful theory of enterprise entities. However, this unification is not overtaking or destroying the individual efforts, it rather allows the significant details of these discipline to fit together”.

After more than thirty years of work on the topic, the vision of the right information for the right people at the right time and in the right format has still not been realised, and it appears that the reason is partly the lack of an underlying
commonly accepted theory, and partly the lack of mature enough tools. The coherency
of information flow has always been the original aim of the discipline of Enterprise
Integration (EI), “The goal of enterprise integration is to provide timely and accurate
exchange of consistent information between business functions to support strategic
and tactical business goals in a manner that appears to be seamless” [10], and since
the 1980s [12] integration of the information flow has been a major strategic objective
– whether integration by design or dynamic integration (interoperation).

**5. Future Issues**

Future issues that remain un-resolved and open for further investigation in this
exciting emerging field include the following:

1. For pervasive and coherent EA practices to achieve more penetration, much more research and development is needed to define feasible pathways for the uptake of EA frameworks and practices and tools, which still have not reached optimum influence and usage within organisations. Current developments in the disciplinary EA-bodies, such as the Open Group, must be supported by academic practice.

2. Traditional management roles, responsibilities and authorities (as well as assumed skills and competencies) may have to change in order for pervasive and coherent EA practice to take a foothold in the armoury of higher management. Demonstration is needed on significant case studies of the benefits of such practice, as successful examples are the best motivators for the adoption of new practices (examples of EA being used in business design include [1, 2, 9, 3] demonstrating virtual enterprise creation, trust, virtual breeding environments, brokering, and other fundamental management problems, although decision support tools are still evolving [14,15]).

3. EA frameworks and practices have to evolve in order to deliver benefits needed for these two audiences. The frameworks need to contain metamodels to define a common terminology to be used by stakeholders, and must also be expressed as ontological theories, so as EA tools can be used to make inferences from architecture descriptions and models for the benefit of such stakeholders. While the requirements have been known for over a decade [2], and are part of the international standard that defines requirements to be satisfied by EA frameworks [6], the metamodels behind today's enterprise modeling tools are often limited to the concepts necessary to deliver the IT function, and not adequate for the full architecture of the firm.

**6. Conclusions**

This paper attempted to outline various deficiencies in the traditional role of
Enterprise Architecture and Architects themselves. It has been argued that a
subordinated role of Architecture has led to a failure to provide effective decision
support to senior business decision makers. A future model has been proposed in
which next generation EA would be positioned to include senior business
management providing effective and full information to the right people at the right time. It is suggested that this re-positioning of Architecture within the modern Organization can have a significant contribution to the timeliness, effectiveness and accuracy of the decisions made by these senior business decision makers.

## References

1. Bernus, P., Nemes, L., Schmidt, G. Handbook on Enterprise Architecture. Springer (2003)

2. Bernus, P., Nemes, L. A Framework to Define a Generic Enterprise Reference Architecture and Methodology. *Computer Integrated Manufacturing Systems* 9(3). pp 179-191 (1996).

3. Camarinha-Matos, L.M., Afsarmanesh, H., Ollus, M. (Eds) Methods and Tools for Collaborative Networked Organisations. Berlin : Springer. (2008)

4. Information Technology Management Reform Act (40 U.S.C. 1401(3)). (1996)

5. Doucet, G., Gøtze, J., Saha, P., Bernard, S (Eds) Coherency Management: Architecting the Enterprise for Alignment, Agility, and Assurance. Falls Church, VA : International Enterprise Architecture Institute. (2009)

6. ISO 15704:2000 Industrial automation systems -- Requirements for enterprise-reference architectures and methodologies. Geneva : ISO (2000)

7. ISO/IEC 42010:2007. Systems and Software Engineering – Recommended practice for architectural description of software-intensive systems. Geneva : ISO (2007)

8. Karvoinen, I. et al (Eds). Global Engineering and Manufacturing in Enterprise Networks (Globemen). VTT Symposium Series 224. Helsinki : VTT. (2002)

9. Ross, J.W., Weill, P., Robertson, D. Enterprise Architecture as Strategy: Creating a Foundation for Business Execution. Cambridge : Harvard Business School Press. (2006)

10.Smith, D., O'Brien, L., Kontogiannis, K., Barbacci, M. Enterprise Integration. *The Architect* 5(4). pp1-14. (2002)

11.Uwakato, U The Intelligent Manufacturing Systems Program. in International friction and cooperation in high-technology development and trade. Charles W. Wessner (Ed). Washington, D.C. : NAP pp205-215. (1997)

12.Vernadat, F. Enterprise Modeling and Integration: Principles and Applications. Berlin : Springer. (1996)

13.IFIP-IFAC Task Force GERAM: Generalised Enterprise Reference Architecture and Methodology Version 1.6.3. (1999). Accessed 1 July 2009 at http://www.cit.gu.edu.au/~bernus/taskforce/geram/versions/geram1-6-3/v1.6.3.html

14.Peñaranda, N., Galeano, N., Romero, D., Mejía, R. Molina, A. Collaborative Engineering Environments for Virtual Organizations. *Int. J. Technology Mgmt* 8(3) pp.298-320 (2009)

15.Noran, O. A Decision Support Framework for Collaborative Networks. *Int. J. of Production Research* 47(17) pp. 4813-4832 (2009)