Tag: Enterprise Architecture

Categories
Strategic Management

A Roadmap is Worth More Than a Thousand Words

Failing to plan is planning to fail is the saying, but to what degree is a plan relevant in a dynamic environment with multiple stakeholders and multiple sources that can impact the organization and strategic plan. The organization’s environment is adding to complexity and the bigger the organization, the more likely the decision makers will experience a high degree of complexity when it comes to the decision-making processes. 

A  roadmap is in other words a great artefact to use, when the decision makers need an overview of how the individual activities and decisions impact the organization and its possibility to deliver on the decided strategy, and likewise can roadmaps deliver the relevant “framework” for making the relevant decisions. But what is needed in order to build a roadmap that can deliver the overview? And is the roadmap the most important delivery?

Complexity in Decision-Making Processes

Medium-sized and major organizations will eventually experience that decision making processes are becoming increasingly complex, which has impacts the time for when and how the decisions are made. The delay of implementing the decisions does the added complexity e.g., in the layers of the organization impacts the organization’s ability to adjust to its environment.

The sources of complexity in organizations are many, but you will most likely experience complexity increase when:

  • New hierarchies are introduced, meaning decisions have to be made by people far away from actual production of the organization.
  • New comprehensive rulesets are implemented and enforced.
  • New structures of the organization e.g., the enforcement of new department structures and new ways of communication.
  • New services, products and processes are introduced and leads to new ways of working where limited existing knowledge is available.

The increasing level of complexity in organizations cater for the establishment of roles like enterprise architect, business architects and solution architects who can coach the different stakeholders of the organization to navigate the complexities and to enable coherences. One method to assist with the guidance of the stakeholders is the use of roadmaps.

Roadmaps

A roadmap has to be individualized for the specific organization and its specific industry. A good roadmap includes perspective for market orientation, business related themes and technical deliverables. It is almost needless to say, but the roadmap must include a time perspective and the perspectives, those earlier mentioned, have to be connected. 

The enterprise architect would have to consider a few different themes before the development of the roadmap takes place, and the primary concern to address during the planning is to consider that the roadmap itself is not the value adding component. The primary value adding component of the roadmap is the process of delivering it. The artefact as such is valuable for communication to different groups of stakeholders, though the value of creating clarity is mainly developed during the roadmapping process, since the activities in most cases would involve executive stakeholders.

The Roadmapping Process

The enterprise architect will have to act as the facilitator and as a subject matter expert, when or if, questions are asked during the sessions in the process by the different stakeholders. Likewise, the enterprise architect can as such not own the roadmap, except, if he or she is a member of the executive committee of the organization.

First and foremost the enterprise architect has to ensure executive sponsorship for the process. When the sponsorship has been ensured, then the relevant stakeholders have to be identified and engaged. The first meetings will likely have to be done individually with the stakeholders, so they are prepared for what will be done during the workshops where groups of the stakeholders are engaged. One of these group workshops would include the kick-off session, which will have to provide alignment and commitment to the process, since without the “geist” or “spirit” to take part in the process for developing the roadmap, then it is likely very little will happen. 

The enterprise architect will also have to work on ensuring a vision is articulated as part of the roadmapping process, and the vision is captured, so the participants in the process can support the mapping of the roadmap towards achieving the vision. The vision and the prework to the roadmapping process can be captured by using scenarios and undergo a specific process for this with the executive committee, so they have an aligned view of the vision, before the roadmapping process is commenced. 

During the roadmapping process the enterprise architect has to ensure that the participants do not begin to suffer from group thinking, since the best possible outcome of the process will be produced by a diverse group of stakeholders, who can challenge different hypotheses and perspectives in the roadmap. This is to be done through the first round of workshops. The enterprise architect will also have to consider engaging the stakeholders individually before the second round of workshops is commenced, since there likely will be a different group of stakeholders involved in these.

The second round of workshops will usually include the subject matter experts e.g., software engineers, solution architects, logistics specialists, sourcing specialists, operations specialists, security specialists and a like. The specialists will during these workshops provide clarifications on how the different deliverables are interconnected, and what impediments have to be dealt with as-well.

The third and last round of workshops in the process of developing the roadmap will be concluded by a presentation for the members of the executive committee. They will have to commit to the roadmap before the organization as such can begin executing as according to it. Before the presentation to the executive committee the deliverables in the roadmap will have to be described as a portfolio of projects (in some cases as portfolios) so program managers and project managers can assist in delivering the projects.

After the last round of workshops have been completed, then it is time to involve the stakeholders in the organization that did not take part in the workshops. This can be done creating a few rounds of presentations so the stakeholders are informed and they can ask questions regarding how to proceed with the roadmap. The stakeholders can prove to be regular employees as well as middle managers like head of departments and senior vice-presidents. Besides the presentations, then “company town hall” meetings can be made use of in-order to spread the knowledge of the roadmap, and in the case of this, the enterprise architect should take part of these to assist answering the questions.

The roadmap has to be published, e.g., at the organization’s intranet, so the executives, middle managers and the employees can look information and “navigate” accordingly. Afterwards, the enterprise architect will have to pivot to a “Plan – Do – Check – Act” approach to make sure the roadmap is kept updated and implemented through the project portfolios. 

Conclusions

The primary value adding activity of developing the roadmap is the process where the different stakeholders take part in developing the roadmap. The roadmap will have to include a market perspective, include business related themes and technical deliverables.

The second most important outcome of the process is the roadmap, which can be communicated to the relevant stakeholders in the company, and in some situations to stakeholders outside of the company. With the roadmap in hand it will become easier for the stakeholders in the company and its environment to navigate the complexity.

Categories
Agile

Going Agile

Agility is the word of the decade, and your organization’s approach to enterprise architecture should support that. Going agile is not the same as going versatile for the enterprise architect, or is it?

The Role of the Enterprise Architect

The enterprise architect is a strategic role in many organizations. The role is strategic in the sense that the enterprise architect designs the strategies and facilitates the implementation of strategies through a series of activities like program, projects and investments. The enterprise architect will therefore be in dialogue with a wide-range of stakeholders and conduct a wide-range of tasks in order to support the strategic part of the role.

Among the wide-range of tasks are empowering the translation of the strategy to strategic plans and to specific products (or services) that have to be implemented. This includes different approaches to ensure the implementation of the desired products. In this case products can be customer-oriented as well as internally oriented in order to enhance specific capabilities (processes, people, tasks and knowledge). When there is a digital edition of the product, then different delivery methods can be applied e.g., agile process models can be used, and in this case the different agile process models require different inputs and coaching from the enterprise architect in order to ensure the best possible products are delivered.

Why is the versatility of tasks needed? The enterprise architect has to go versatile in how he/she approach tasks. In order to succeed with this the enterprise architect has to apply a Plan – Do – Check – Act approach, which is known from the systems thinking paradigm. This approach empowers the enterprise architect with defining the strategies and ensure the implementation of them afterwards:

  • The enterprise architect has to be involved in the planning process.
  • The enterprise architect has to be involved in implementation processes.
  • The enterprise architect has to be involved in the check-up on the implementation.
  • The enterprise architect has to be able to correct any deviation. 

The agile frameworks can empower the enterprise architects to fulfill this role by applying the frequent planning, commitment and follow-up. This means the enterprise architect can ensure progress by being versatile in how to deal with the tasks at hand and integrate with the agile processes applied for the digital deliverables. Additionally, it has become more and more apparent that physical products can be improved by having a digital twin and it supports the need for the enterprise architect to take part in agile processes and to take part in the design processes.

Agile Process Models

There are many different agile process models to ensure the development of digital products, though the process models most likely also can be used to develop other types of deliverables, providing different possibilities for the enterprise architect to facilitate the right products and services being developed. I will briefly walk through three different agile process models that can empower the enterprise architects to implement the strategies and design superior products.

LEAN Development:

The LEAN development model is based upon seven principles for how to structure the development process of digital products. One of the principles states that “Decide as late as possible”, which also indicates that different alternative solution designs have to be made available and presented for the stakeholder (product owner) who can decide what features to include in the product. The enterprise architect will in this particular process model act as the product owner or alternatively as the designer of the different designs that could be implemented.

The second principle that can prove to be interesting for an enterprise architect by using this process model is the “Optimize the whole”. This would mean the enterprise architect would have to guide the development team on how the “whole” of the software solution should be optimized and to what level. This can be done by the enterprise architect e.g., in the role as the product owner, but if needed the enterprise architect can to some extent provide guidance for the solution blueprint on what to be optimized.

The last principle in LEAN development that proves to be relevant for the enterprise architect is “Empower the team”, which means that the enterprise architect has to provide the relevant organizational structure and the relevant patterns in order to provide the team the ability to develop the relevant digital deliverables.

Scrum Development:

The Scrum Agile Framework (scrum) consists of a process framework that involves sprints of two to four weeks, depending on the setup the organization wants, though the most normal sprint length is two weeks, which includes testing of the new features. In addition to the sprints a daily scrum is hold were the development team and the scrum master will facilitate the a meeting on where only three things are on the agenda:

  • What has the individual developer done the previous day?
  • What is the individual developer planning to do during the present day?
  • Do any of the individual developers experience problems?

The development team demonstrates the delivered software features in the end of the sprint, and this empowers feedback from the product owner (the role which the enterprise architect can take). The product owner is also responsible for coaching the development team in-order to make them understand what features are to be developed. Likewise, is it the product owner that decides if the features have been delivered as planned. On the other hand, the product owner is responsible for providing the clarifications required by the software developers.

The scrum methodology does also include an approach that includes to some extent autonomous teams, which means the enterprise architect in this case would have to empower the developers to choose the right tools, frameworks and standards, but also to clarify how the different digital deliverables fits together and works well together. In other words, in this particular approach it is relevant that the enterprise architect is able to provide the blueprint for the content as well as the patterns to be used to deliver upon the content.

Extreme Programming:

The last approach to conduct agile software development is known as Extreme Programming (XP). This approach can also be used by organizations and enterprise architects. The “XP” approach is slightly different from an enterprise architecture perspective than the other approaches. From an enterprise architecture perspective, then the different deliverables have to be organized according to each-other and to provide coherence in the solution portfolio. This is where the enterprise architect is able to provide value of the team. Extreme programming does also include a principle about “listening” and by having engagement with the customer, and in this case the enterprise architect can act as the stand-in and ensure the features are translated for the development team. The problem regarding structure and optimization is also apparent with the extreme programming approach and in this particular context the enterprise architect will be able to provide the overall roadmap and the development framework for the development team e.g., through patterns and standards.

Conclusions

The enterprise architect will have to be versatile in his/her approach to deal with tasks in the relation to “translate” for the business strategy into relevant activities and products. This means the possibility to deal with (software) product management is one of the tasks that the enterprise architect has to be prepared to deal with effectively. Hereto, the enterprise architect has to ensure the roadmaps for the products are planned and available. Lastly, the development framework has to be setup and governed by the enterprise architect in order to ensure the empowerment of the different development teams, so they are able to deliver maximum velocity and deliver the digital deliverables.

Categories
Enterprise Architecture

You Should Always Apply an EA Framework

While you analyze and implement the organization’s to-be enterprise architecture you will have to apply a framework, or do you?

Role of the Framework

The enterprise architecture framework plays with interesting role when it comes to the empowerment of enterprise architects by providing: 

  • Providing examples on artefacts that can contain the relevant information.
  • An overview of information that has to be uncovered.
  • Identifying gaps in the collected data.
  • Identifying how information is to be collected and in what order.
  • Speeding up clarifications and implementation of identified changes.
  • Speeding up information collection and information processing.
  • Applying best practices to analyze impacts when the new initiatives (projects) are implemented.
  • Following up on enterprise investments.

Advantages of a Framework

Organizations applying an enterprise architecture framework can benefit from some advantages compared to organizations that do not:

  • Proven methods.
  • Knowledge is usually available.
  • Different templates support the use of the frameworks.
  • Communities of practice.
  • The advantages mentioned in the former chapter.

Disadvantages of a Framework

Though there are many advantages of using an enterprise architecture framework, then there some disadvantages by using a framework: 

  • You will have to follow a standard.
  • Frameworks rarely appear intuitive for stakeholders.
  • Time is consumed on a method and not on content creation.
  • No scope on cash flow.
  • Some frameworks require certification, which can add costs of operations for the organization.
  • Adaption of the framework for the individual organization. Does the framework suit the needs and requirements of the individual organization?

Observations

I have personally never worked in an organization that has adopted an enterprise architecture framework. The organizations have on the other hand been perfectly able to do fine without. However, the organizations could also do better. 

The EA teams in each of the organizations could have used more effort on choosing a few artefacts that could prove additional value for the stakeholders e.g., artefacts related to project initiation, principles for investments, standards and business processes or system landscapes.  Additionally, the individual EA teams could develop the requested artefacts iteratively through lean principles in order to get and process the relevant information that makes each of the artefacts usable. In other words, one step at a time, and just enough – just in time.

Conclusions

Most organizations can easily apply a few core artefacts and gain the relevant impact on their organizations. Consequently, you and your organization do not have to implement an EA framework for your to-be analysis, though the organization might be able to harvest some benefits by doing so, though it does also comes with a price.

Categories
Enterprise Architecture Strategic Management

Enterprise Architecture Starts from the Top

There is no doubt on the topic. If you want your organization to harvest the benefits of strategic planning and digitalization, then you will have to apply enterprise architecture, and your approach has to be top-down, or does it?

Strategic Management and Planning

Organizations of all sizes have some form of strategic planning even if they claim they do not, since not having a strategic plan is a choice on how to (or not to) plan and how  to identify opportunities, e.g., this could ad-hoc. All organizations regardless of these are private, public or NGOs make choices regarding strategic planning and their strategies everyday and every year. Organizations who fail to do strategic planning on top-level (executive committee or board of directors) will experience that employees or middle managers will do some form of planning that can impact the ad-hoc strategy one way or the other.

Strategic planning and strategic management can have different results and outcomes depending on how the organization chooses to apply the different methods and tools in the different stages of the development of the strategic prioritization. On the one hand, organizations that invest time and resources in doing the strategic management and planning that involves the right stakeholders and the right level of activities will experience better outcomes than organizations that do not invest in their strategic planning capabilities. On the other hand, regardless if the individual strategic plan fails, then the ability to develop coherent plans are valuable in any situation and crisis management.

Failing

Strategic plans fail, some indications are up to 90 % or so, since the top-management or alike are not committed to implementing the strategic plans or the objectives have not been defined properly or the plan has not been defined in a way that takes the organization’s environment into consideration, and therefore is not valid for implementation, when time and resources have been allocated.

Schools and Planning

There are different schools for conducting strategic planning and strategic management. Mintzberg has identified 7+ schools for strategic management and strategic planning. These schools have different pros and consequences while conducting strategic planning and articulating strategies. 

The different strategy schools is a broad theme that I will publish a blog post about later on, though the point in this particular context is that though strategic planning and strategic management has a tendency to fail, then there is a bright light at the end of the tunnel. Keep in mind that as long as a strategy and strategic plan provides multiple options for organization to make use of, then it is more likely to succeed, and if these options have been tested with different potential outcomes then it is more likely that the strategy and strategic planning can prove useful. The different outcomes can be based on different techniques such as scenario planning and roadmapping, which are tools that encourage involvement from different stakeholders in order to ensure the outcomes are done right.

The different schools and different paradigms that can be used to empower the strategic planning process, though in general it seems like the strategic plan has to be anchored in the top of the organization in order to make it possible to implement the strategic plan:

  • The board of directors have to accept the strategic plan and its framework, and thereby allocate the budget for implementation.
  • Members of the Executive Committee have to approve the plan and ensure resources are allocated.
  • Vice presidents, managers and team leads have to ensure the right persons and the right time and other resources are available.

Enterprise Architecture

Bernard (2012, p. 33) defined enterprise architecture is the combination of strategy, business and technologies. As such enterprise architecture is an approach to ensure coherence of planning and implementation of future designs for enabling the defined objectives. One of the core perspectives of using enterprise architecture as a methodology for strategic planning is to differ between the As-Is situation for the organization and the To-Be situation for the organization. The process of defining the blueprint for the To-Be situation for the organization is usually described in enterprise architecture frameworks. Enterprise architecture frameworks includes the need to define the business strategy and thereafter define:

  • Business Architecture (e.g., business processes, business rules, product features, principles for business development).
  • Information Architecture (e.g., information processing, data dictionaries, data maps and mapping, GDPR processing overview etc).
  • Technology Architecture. (e.g., system landscape, standards for software development, overview of infrastructure components).

The EA frameworks usually define a set of artefacts for each of the different types of architecture forms.

Sadly, in most organizations the enterprise architecture team is anchored in the information technology department and not in the business units, which means that in many organizations then the approach for enterprise architecture becomes too IT-centric, and consequently the organization will not be able to harvest the full potential of using enterprise architecture. The problem with IT-centric enterprise architecture is that technologies in itself is not particularly strategic, in fact, in most organizations technologies can at best be considered a theme that is dealt with on a tactical level.

Technologies and Digitalization

Enterprise architecture can empower organizations to get a higher return on investments of their use of information technologies. This will usually be done through a digitalization perspective, which means that the business practices and customer experiences are to be optimized by the use of information technologies. In this light it would say that the current practices are to be re-engineered to fit better in digital interactions with new tools and platforms to support the dialogues needed. Digitalization requires that business opportunities and problems are addressed and not as such new technologies that are identified for implementation.

Enterprise architecture that is too IT-centric will usually do this the other way around, meaning that the individual enterprise architects change their mindsets to identify how business problems either can be solved with existing technologies (in the organization) without scope on solving business problems, and over time it will become apparent that business stakeholders begin to avoid the enterprise architects since they will not provide the desired outcomes for them. To some extent then the too IT-centric enterprise architecture approach will lose its ability to impact the organization’s business strategy and thereby lose its ability to stay strategic, and as such the scope changes from a top-down approach for enterprise architecture (which ensures impact) to a bottom-up or at best middle-out. The middle-out approach would lead to more benefits across the organization, but as such it will not impact the overall strategy, and this approach cannot be considered strategic.

Conclusions

Enterprise architecture that leads to great impact on the organization has to be anchored in the top of the organization, as it would be, with strategic planning. This means enterprise architecture has to be business centric and to some extent be situated in the business unit and not in the IT-department. Enterprise architecture teams that are anchored in the IT-department have to work on staying business centric in order to avoid being too tactically oriented, and by that ensure their inputs can be implemented on a strategic level in the organization. In this light, it is possible to do enterprise architecture with a bottom-up approach or a middle-out approach, but the outcomes will not be as significant as with the truly top-down approach to enterprise architecture.

Sources

Bernard, S.A. (2012). An Introduction to Enterprise Architecture. Authourhouse.

Mintzberg, H., Ahlstrand, B. & Lampel, J. (2009). Strategy Safari. Prentice Hall: London.