Warning: upon reading this article, your architectural thinking in your entrepreneurial brain can boost substantially.
The context of this article is based on a three-pronged business perspective: 1. new business, 2. modernising iteratively, and 3. transforming the current business capabilities to desired versions.
I offer the use of an architectural approach empowered with design thinking principles. I practised this approach and the principles over the last three decades in many large and complex business organisations by developing practical solutions at the enterprise level. My silver hair is an indication of many sufferings in those chaotic situations.
The major theme of this article is to turn chaotic situations to coherent states. Our focus is to generate new business insights by iteratively modernising and transforming the business capabilities by leveraging digital technology stacks, processes, people, and tools.
Undeniably, creating a new business from scratch is challenging and requires a multi-faceted approach from entrepreneurial leaders. At the highest and most fundamental level, it requires an inventive, innovative, result-oriented, and collaborative mindset with substantial effort and time investment. However, generating new business using modernisation and transformation initiatives can be relatively faster and more economical.
Both iterative modernisation and radical transformation initiatives require architecting the solutions using agile methods and design thinking principles with an innovative and collaborative approach. These initiatives can be a long and stressful journey to move the enterprise from chaos to coherence. The process includes, not only business capabilities and the technology but also requires factoring every other aspect of the enterprise. Even though enterprise information systems look only a tiny bit of an organisation in an overarching enterprise, this domain by itself can be gigantic especially for the large business organisations.
Enterprise information systems, in general, can include business capabilities, technology processes, data, information, applications, infrastructure, support, and service delivery domains. These domains can even be more complex with the addition of geographical factors, such as adding multiple countries or states to the equation. The good news is that these primary domains and geographical factors can be modernised and transformed iteratively in parallel with agility. It simply must be architected with rigour!
Both a top-down and a bottom-up approach, with a tiered model, can be applied to expedite the solution activities. As an encapsulated view, at the top tier business capabilities, data, information, and applications, at the middle tier technology processes, and at the bottom tier the underlying infrastructure can be placed strategically. These domains can independently be modernised and transformed using parallel solution activities. However, an integrated approach is essential as there can always be dependencies and inter-dependencies from multiple angles and layers.
I walk through the approach, in the simplest possible form, by wearing my enterprise architecture hat. [However, let me give you one more caveat that some of my experienced based guidance in this article may mildly conflict with the content in the traditional text books. Frankly, no one cares about them whilst dealing with real chaotic situations]. Experience can beat the theory in chaotic business environments.
Once the strategy is set at the organisational level, we refine the strategy and convert it to the architectural vernacular in agility. The strategy document is a critical artifact to bring all parties and stakeholders on the same page. Then we identify the critical dependencies among these domains based on the short term, midterm, and long term considerations.
Let’s take a deep breath and quick smile so that we can digest the rest of this article better.
Okay, we are back to reading with fresher eyes and clearer mind.
By using the strategy guidelines developed based on organisational vision, and considering the known dependencies, we develop a high-level solution roadmap to inform the sponsoring executives. This draft roadmap can indicate the key outcomes, timelines, and a ballpark cost model for the overall solution goals. This indicative proposal can be at a very high level as there may be many more factors which can potentially affect timelines, resources, and the cost of the proposed solution.
Once the roadmap for the initiative is set, we need to conduct a comprehensive viability assessment considering the current state of the in-scope initiatives, indicative future state, and the strategies to reach the end state. This viability assessment must include key risks, constraints, assumptions, and dependencies. The viability assessment can be one of the most informative tools that an enterprise architect can provide to the sponsoring executives, who can make informed decisions for commercial and financial aspects of the initiatives. These sponsoring executives usually focus on critical financial points and keep questioning total cost of ownership and return on investment for the initiatives.
After review and approval of the viability assessment, we delve into collecting the high-level requirements of the solutions based on the domains mentioned earlier. As dealing with the requirements of those domains can be daunting and span across multiple domains and relate to a myriad of solution components covering both functional and non-functional aspects, we delegate the requirements collection process to the domain, portfolio, and program architects, supported by business analysts. In this phase, our role is to coordinate and facilitate the requirements management team as requirements really matter!
After requirements are collected and analysed at a reasonable amount, supplemented with core use cases of the solution, the next important activity is to prioritise the requirements traceability activities based on business impact. We can develop a set of criteria to prioritise the requirements considering the factors depicted in the strategy and roadmap documents, as well as smartly interpreting the financial and business priorities set by the sponsoring executives.
Due to realities of life, architecting modernisation and transformation initiatives definitely requires making trade-offs to reach optimal solution outcomes. When making trade-offs, we must consider several crucial success factors, such as cost, quality, functionality, usability, scalability, security, compliance, capacity, and many other non-functional aspects within our scope, strategy, roadmap, requirements, and use case artifacts.
By the way, you may ask what is an architectural “trade-off”. We can define a trade-off as, creating a balance between two required yet incompatible items. In other words, a trade-off is a compromise between two competing options. It is possible to make a trade-off between quality and cost for particular items. For example, in a solution, we may need to define the interfaces of an application, such as one way or bi-directional, and make required trade-offs for each option to reach the desired goal. To enhance usability of a solution, we may consider use of pre-built widgets for the dashboards as a trade-off for cost.
We must make architectural trade-offs for dealing with uncertainties in the lifecycle of the solutions. For these types of trade-offs, established techniques such as comparing, connecting, and contrasting can be beneficial. Our trade-offs must be crystal clear to the sponsoring executives explicitly highlighting, architectural, design, functional, operational, financial, and commercial implications of the options that we propose.
Each trade-off that we make for the solution constructs must be supported by solid architectural decisions. These crucial architectural decisions can have substantial business implications for the success or failure of our initiatives.
We must create architectural decisions very carefully, measurably, rigorously, and agreeably. Why do we need such a disciplined approach? Because, each architectural decision can have a severe impact and multiple implications on the business outcomes. Another reason is that changing the architectural decisions at later phases of the solution lifecycle can be very costly, time-consuming, and chaotic. Let’s keep in mind that our ultimate goal is to turn chaos to coherence.
Some implications of architectural decisions can be related to cost, compliance and constraints, while others can relate to non-functional aspects such as performance, scalability, capacity, availability, security, and usability. In addition, our architectural decisions must be validated with subject matter experts and communicated with multiple stakeholders for their acceptance and approval to reach the optimal consensus on the validity of the decision. Reaching consensus on decisions is one of the critical success factors for turning chaos to coherence.
After creating the architectural decisions, reaching consensus, and obtaining necessary approvals, the next challenging task is to provide a representative picture of the architectural framework for the initiative in a single page. This illustrated representation is usually called the system context showing the architectural framework with critical dependencies. System context is a work-product template which can be found in many established methods. Without developing a crystal clear system context, we cannot turn chaos to coherence.
Creating a system context requires abstraction skills. This means that we need to represent a large volume of information in a tiny diagram by setting concise relationships among the system components in the architectural framework. We can apply the proverbial principle of ‘a thousand words in a single picture’. Setting the context for the framework can help us communicate it to relevant stakeholders in a common and understandable manner. In short, the system context adds clarity to understanding the proposed architectural framework for our solution initiative. This abstract thinking skill is an example of our architectural intelligence for turning chaos to coherence.
So far, we covered the core architectural approach from 30 thousand feet view. The lifecycle for the architecture process continues with more activities reflected upon various artifacts. As my aim is not to bore you with granular details and give you take away points to turn chaotic situations to coherent solutions, I quickly jump to the next critical point -design thinking- and introduce you the importance of it briefly as it really makes difference in your architectural intelligence for turning chaos to coherence with a sense of urgency.
In the architecture lifecycle, designs can be at high level or detailed level. Design thinking principles can be applied to both levels. In fact, design thinking process starts with the strategy phase and commonly used in the requirements management phase. The prime design thinking principles are user empathy, problem framing, solution focus, effective representations, abstractions, modelling, abductive reasoning [this is not misspelled as some editors keep crossing out this word], agility, diversity, innovation, and collaboration.
Design thinking activities can take place daily in various team interactions, especially in agile scrum stand-ups [they are fun activities]. Applying design thinking principles can allow the team to be intuitive and logical at the same time. This practice enables team members to be more creative in recognising new patterns. As design thinking is closely associated with the agile approach, the design thinking professionals progress their ideas iteratively. Design thinking principles are well recognised in the industry and widely adopted in many modernisation and transformation initiatives as part of the core organisational culture and the radically transforming ecosystem from a chaotic situation to a coherent state.
I highlighted the design thinking in the context of turning chaotic situations to coherent solutions because design thinking practice can be an ideal tool for entrepreneurs both for creating new business opportunities and transforming the current business capabilities resulting in new business insights. Design thinking can add a new dimension to our entrepreneurial pursuits while moving our business from chaotic situations to coherent states.
Dr Mehmet Yildiz 