Basing Enterprise Architecture on Business Strategy: 4 Lessons for Architects
Rod Dilnutt
Director, William Bethwey & Associates | Industry Fellow, The University of Melbourne | ACS Management Committee
We commonly accept that Enterprise Architecture is informed by business strategy. This assumption is deeply embedded in our mainstream methodologies, so why do so many architectural projects go wrong at great operational and financial cost?
Our research at The University of Melbourne has found that there are four fundamental preconditions that must be assessed before commencing any architectural development:
- Is there a well-articulated and agreed Business Strategy?
- Does this Business Strategy provide clear direction?
- Is the Business Strategy robust and have the flexibility to respond to rapid change?
- Business strategy creates legacy ICT
These factors were first identified in the early 1990’s however, many organisations have not heeded risk warnings and if we are to maximise the return on investment from EA now is the time to adopt some simple principles before proceeding to develop any architectures.
Let’s look at the issues in turn.
Is there a well-articulated and agreed Business Strategy?
Common sense tells us that there must be a Business Strategy before commencing EA development. However, Gartner (2016) reported that “two-thirds of business leaders are unclear about what their business strategy is, and what underlying assumptions it is based on”.
If the Business Strategy does not exist or has not been clearly articulated, agreed and widely communicated then it is no wonder that any EA will struggle to be fit-for-purpose.
Lesson: The architect must clarify the business direction so that the EA is built on solid foundations.
Does this Business Strategy provide clear direction?
The problem of formulating business strategies and plans in a way that does not provide any clear actionable direction for EA been recognized for a long time. EA includes: platforms, application portfolios, operating processes, people structures and infrastructures however, there can be a tendency to pronounce strategy in abstract terms. This can be very difficult to interpret for subsequent EA design and deployment. For example: “general statements about the importance of “leveraging synergies” or “getting close to the customer” are difficult translate into concrete capability.
Lesson: As EA intends to bridge the communication gap between business and IT stakeholders, facilitate information systems planning and thereby improve business and IT alignment the architect must ensure the fundamentals are clearly articulated.
Is the Business Strategy robust and have the flexibility to respond to rapid change?
Even when organizations have clear and actionable business strategy, this strategy is often unstable, frequently changing and unable to provide a steady basis for planning IT. We live and work in a world of rapid change. This turbulence can originate from many sources including advances in technology, changed social values, regulatory obligations and marketplace expectations. Internally, changes in strategy, leadership, and operating models increase the challenges to create robust yet responsive EA.
Lesson: The architect must risk assess this volatility and plan accordingly. This will always be a challenge but ‘forewarned is forearmed’ and the current focus on agility is helpful here, and activity must be planned to avoid anarchic islands of capability.
Business strategy Business strategy creates legacy ICT
Finally, there is a paradox in that after being developed and deployed, ICT typically exists in organisations much longer than the business strategies or strategic initiatives they were intended to support. Even when organisations have a rather clear, actionable and stable business strategy, this strategy often requires highly specific, ICT components to create competitive advantage however, these may have limited shelf-life as technology and management innovations overtake their usefulness. Thus, creating the perennial problem of legacy ICT or ‘alignment traps’.
Lesson: Take a long-term view but be prepared to compromise to create business opportunity
The role of the Architect
Each of these four areas require the architect to engage closely with business leadership. Only through close engagement will alignment of Business strategy and EA be achieved. In some architect functions this will require a rethink of the role and development of engagement strategies and skills. A starting point can be to use the following risk assessment framework as a communication tool to provoke discussion and better understanding.
Figure 1 – Business Strategy – EA Risk Assessment
Close
The assumption that business strategy is the basis for EA needs to be risk assessed and evaluation of these four factors can provide the architect a sound place to start and open the dialogue with business leaders. Identification of the four problems associated with business strategy informs that assuming business strategy will provide the clarity and direction required to anchor EA as a value-adding business asset creates a significant risk exposure. However, this can be overcome by a simple risk assessment.
Click here for a copy of the formal publication: Can Enterprise Architecture Be Based on the Business Strategy published in the proceedings of the 53rd Hawai’i International Conference on Systems Sciences. 2020.
Authors: Dr Rod Dilnutt, A/Prof Sherah Kurnia, Dr Slava Kotusev.
Enterprise Architecture, Strategy, Architecture Practice, People Leader
4 年Key skills/knowledge for Enterprise Architects are a good understanding of the business and an ability to network with senior business stakeholders. If this does not result in the development of business strategy along side the business it will at least lead to meaningful assumptions. It’s lack of business acumen and networking that leads to shelf ware, even if there is a business strategy in place.
Director, Architecture, Cloud and Emerging Technology at the Future Fund
4 年Thanks for sharing Rod.? An alternative approach in the absence of an agreed business strategy (quite often the case) is to document the business strategy assumptions and have them validated.
Director, William Bethwey & Associates | Industry Fellow, The University of Melbourne | ACS Management Committee
4 年Many thanks for your comments.? If anyone is interested in Joining us at our first industry forum to discuss?Enterprise Architecture in the 2020s' at The University of Melbourne 26 March, register here. https://events.unimelb.edu.au/events/preview?id=14166-enterprise-architecture-in-the-2020s-an-exploration-of-the-art
Business Analysis & Project Management
4 年Thank you for sharing this Rod Dilnutt . Some really good insights.
Sr Integration Analyst
4 年Thanks for sharing Rod! (I used to be your student by the way). In most of our engagements with the clients, we tend to advise them to think of the automation project as business strategy reform program in which we are just not automating one process, we are assessing the As-Is state of the existing EA and provide recommendations so clients can progress to a better To-Be stage. The analysis work for the As-Is is usually the most challenging part because very often people do not know or the knowledge only sits with the architect. So our method involves using an analysis toolset to bring visibility of the As-Is to all stakeholders and get their consensus on it. In case you wondering, the tool we use is from IBM, IBM Blueworks Live.