With the digital transformation and new digital technologies that are impacting almost all business models, organizations must adapt quickly to these changes to avoid being outperformed by competitors. Tech companies and start-ups are constantly challenging well-established organizations by expanding their business areas with their agile way of working. Numerous examples show how agile and tech driven companies are successful across many different industry sectors, e.g., automotive, e-commerce, traveling and finance.
For any enterprise-wide transformation initiative and in particular the digital transformation of organizations, architecture is a key success factor on several different levels:
- Software Architects implement digital transformation initiatives with their technical expertise and leadership of software developers.
- Enterprise Architects have a holistic view on the organization across departments within IT and business. They define the IT strategy and monitor their execution through project initiatives.
- Business Architects optimize business processes, reduce unnecessary business complexity, and harmonize products, processes as well as data models.
- In addition, important technical roles and cross-cutting concerns are often covered by specialized architects, e.g., security, data analytics, networking.
Despite the importance of architecture within the transformation process, many organizations struggle to establish a successful architecture practice, e.g., due to the well-known “ivory tower” antipattern in which architects have no impact on actual projects. Another problem is that architects and their expertise are highly critical resources, and their valuable time needs to be prioritized better, e.g., architects working on trivial topics or spending too much time in useless meetings. For both situations, this article offers an overview about the key responsibilities for a successful architecture practice.
This article summarizes the key aspects that must be considered for a successful architecture practice. The subsequent articles will cover the six dimensions in depth. The knowledge presented in these articles is based on profound research and longstanding practical experience from all contributing authors. All articles are thoroughly reviewed and quality assured. In the following, we go into more detail on the six individual dimensions of the OPF Architecture.
Governance & Standardization
Governance and standardization are means to provide guardrails for projects, and this also holds true for agile projects. In this article, we described why missing standards and guidelines are an antipattern for large-scale agile initiatives [1]. Defining good standards is not a top-down effort. Instead, project experiences need to be incorporated through an RFC (Request for Comments) for architecture standards.
This improves quality of architecture standards since experts are included early and projects are more willing to adhere to them.
With the large number of projects in an organization, it is very challenging to ensure all of them adhere to the standards.
Recent research proposes new approaches to establish architecture standards in large-scale agile initiatives [2], [3].
Community & Knowledge
One underestimated area of a successful architecture practice is community and knowledge, even though benefits can be achieved relatively quickly in comparission to the other areas. Communication and communities are important success factors for architecture practices. They can serve as a “virtual” organization in which people with similar skills and experiences help each other out. An architecture community can include regular presentations from projects for all architects globally. Once such an architecture community is established, it can also be leveraged for governance purposes, e.g., communication of new binding standards.
Architects from different departments can share ideas, reference architectures or reference implementations. Enterprise Architects are good candidates to run and moderate this community. This will also help avoid the “ivory” tower antipattern.
Vision & Strategy
In some industries, it is legally mandatory to have an IT strategy approved by the board of management. Besides this requirement, having a common vision and strategy is important for several other reasons. First, it ensures alignment with the business strategy of the organization. Second, it captures and communicates important decisions that are relevant for all projects, e.g., what is the cloud strategy. The ownership for the IT strategy might be different in every organization, but there should be one chapter (at least) on the target architecture / landscape, for which Enterprise Architects are responsible.
The biggest challenge with the vision and strategy is to find an appropriate level of detail that is helpful for projects.
Architects have the only role in organizations that can provide the required level of detail to achieve this. Even if software development is outsourced to external providers, it is critical that architects are aware of the vision and strategy. Architecture decisions have a tremendous and lasting impact on the organization. Because of these circumstances, architects must translate the technical strategy from management level to the development teams.
Technical Perspective
Technical perspective includes technical leadership and management, as architects must guide and lead software developers through e.g., code reviews, technical decision-making and consulting of business owners. This can include the implementation of transformation projects that reduce technical debt or ensure operational stability. The key competence of every architect should be the design and delivery of high-quality solutions. While business experts are accountable for correct requirements, architects are accountable for quality of the solution (non-functional requirements). Because of this, architects must be able to prioritize part of the development effort and project budget for technical reasons.
Managing the technology stack requires reviewing new technologies on a constant basis to ensure the best tools, frameworks, and solutions are used to fulfill the business goals.
A technology trend radar for the technology stack can be a good starting point to ensure standard technologies for the majority of projects. However, it should also allow enough flexibility to evaluate new technologies in pilot projects. Another good possibility to support projects is the offering of architecture reviews following a structured approach to find improvements or potential problems.
One of the areas that is often neglected by architects is the monitoring of operations. This can provide valuable insights into different aspects such as outdated libraries that lead to security vulnerabilities. Performance and usage monitoring are helpful to identify critical parts of the application landscape. Problems in the architecture might be visible early before actual outages happen in production. Finally, monitoring of costs is also helpful to make the right architecture decisions or can be used to deliver arguments for technical transformation projects.
Management Perspective
From a management perspective, two main points are relevant regarding architecture. The first deals with the benefits of architecture. Enterprise Architects are not funded directly by projects or business initiatives since they deal with overarching concerns, and therefore it is important to measure their benefits. Measuring benefits on an enterprise architecture level is quite difficult, but research offers ideas, e.g., to measure IT complexity.
If top management support for Enterprise Architecture initiatives is in place, the second goal is to establish an organizational setup that has the right balance between strategy and execution throughout projects. This includes the different roles and responsibilities for architects, e.g., Enterprise Architects, Chief Architects, Solution Architects etc.
Tools
Tooling is crucial for the establishment of an architecture practice, but it can also waste valuable time and resources in case it is not done correctly. Rather simple to implement, a good starting point is the establishment of a common template for solution architecture documentation. This must be mandatory for all projects and can be based on existing best practices such as arc42 [4]. Depending on the experience level, it may be required to provide additional training to IT architects and some good examples as a starting point. This documentation should also be available to other projects within the organization since the main purpose of architecture documentation is communication.
Most organizations already have an Enterprise Architecture (EA) tool in place, but usually they struggle to keep the data up to date or they are unable to take advantage of the data captured in the tool.
One important aspect is to integrate the EA tool with other existing tools, e.g., configuration management, or project portfolio management. Usually, EA tools are expert tools and difficult to use for people that are not trained to use them. Therefore, it makes sense to integrate the EA Tool with corporate wikis. Wikis and other collaboration tools (which are usually already in place) need to be integrated depending on the concrete use case [5], e.g., to provide an architecture knowledge hub.
Recent research showed how governance can be improved with tools such as the Architecture Belt [6]. Ensuring standards and compliance is often not done properly on the project level, or it is a manual time-consuming process. With these new solutions, fulfillment of standards is automatically tracked to allow the necessary transparency. It also provides feedback that can be used to improve existing standards.
References
[1] Hauder M., Frank O., Perkens-Golomb B. (2021) No Rewards, No Penalties. In: Seven Deadly Sins of Agile: Seven Sins of Agile 4/7: No Rewards – No Penalties | LinkedIn
[2] Uludağ, Ö.; Nägele, S.; Hauder, M.: Establishing Architecture Guidelines in Large-Scale Agile Development Through Institutional Pressures, AMCIS: Americas Conference on Information Systems, Cancún, 2019.
[3] Brosius, Maximilian; Aier, Stephan; Haki, Kazem & Winter, Robert: Enterprise Architecture Assimilation: An Institutional Perspective. 2018. Thirty Ninth International Conference on Information Systems (ICIS 2018). San Francisco, CA.
[4] arc42 Template: https://arc42.org/, last accessed on 26.10.2022
[5] Fiedler, M., Hauder, M., Schneider, A.: Foundations for the Integration of Enterprise Wikis and Specialized Tools for Enterprise Architecture Management, 11th International Conference on Wirtschaftsinformatik (WI 2013), Leipzig, Germany, 2013.
[6] Uludağ Ö., Nägele S., Hauder M., Matthes F. (2021) A Tool Supporting Architecture Principles and Guidelines in Large-Scale Agile Development. In: Zimmermann A., Schmidt R., Jain L. (eds) Architecting the Digital Transformation.
