What every Software Architect should know about the business in Digital Enterprise?
I work in the IT field for around 20 years, and hired tens of Software, Technical, Application and Solution Architects. Working at both product and consulting companies it came clear to me that the most of Software Architects don’t always understand Why they’re being asked to build the software they build. Some of them don’t even ask that question. Such behaviour typically leads to sub optimal decisions, over-complicated solutions, and unused systems, along with unhappy project sponsors, frustrated engineering team and unsatisfied users.
History
Business software exist for more than 70 years but the reason to invest to is is continuously changing. Back in seventies software was mostly used for the scientific purposes or complex but specific computations. Around nineties for the first time PCs became a commodity for the offices. The Dot-com boom in late 1990 — early 2000 revealed to lots of the industries an ability to gain competitive advantage on the market building the software, even though the bubble crashed.
For the last twenty years we’ve seen growth of BigTech companies, such as Amazon or Google, which made software its core value stream generating revenue. Whilst some industries are still catching up, looking at IT as an expense to run the business instead.
Digital Transformation becoming a norm and appearance of roles like Chief Digital Officer represents broad adoption of the ability to build competitive advantage with the software across all the industries.
How does all of the above is related to the Software Architecture one would ask? As soon as software starts generating revenue in becomes the backbone of companies success and survival, making every architecture and design decision much more valuable and risky.
It is assumed as a given for an Architect to have great tech skills, and over the last years the demand to understand the business have grown substantially.
Business analysis
Business analysis accompanies the Software Architecture for a while. It’s quite common to have dedicated people fulfilling such role, it is also not uncommon for engineers to execute it.
Definition of a business process could be done using the BPMN, covering roles and their interactions. Looking at well defined BPMN I find it not so hard to build a software implementing it.
But sometimes you may stumble upon a challenge, that the software you built doesn’t receive such a great feedback, or is not well adopted by the end users. Applying series of patches may not help, and typically leads to complications and fixes of corner cases, taking you away from the goal.
But what is the goal? How to ensure you understand the goal?
Business capabilities
Thinking of Why, What and How questions, I’d name business processes answering question How.
Business capabilities defines What business needs to be able to do to achieve an outcome as a part of it’s mission (good article). Capability definition doesn’t describe How it should be achieved, delegating it to business processes as implementation detail. In other words, Capability focuses on competencies company needs, whilst business process defines how company does it.
Imagine you’re a part of a Retail company, willing to trade online (Why). To do so, you require a capability to market your products online and provide an ability to place an order for a segment of your customers (What). To be at the top of organic searches you do SEO friendly product description pages with a process of managing your product data (How).
Another example would be a business process of hiring window cleaners (How). For a cleaning company, it’ll implement one of the core capabilities for making premises clean (What). But in contrast, the same capability for non cleaning company could be implemented in a different way, by having a robust procurement process of hiring cleaning partner (How) to keep the premises clean.
It comes clear, that along with What and How, it would be great to understand Why, ensuring you put the focus in the right place.
Criticality of capabilities
I find it a rare case, when business talks about Why when asking for some software, it is also not so common to talk about What. Asking these questions always brings a lot of value, at least by making yourself knowing where and when to put your attention, and which areas are of high criticality or value.
Taking an example above, for the cleaning company recruitment of window cleaners would be a critical process affecting lots of value. For a regular company, this process would be neither critical nor generate lots of value.
Now let’s have a look on another case, a Retail company. Say it has 95% of revenue coming from offline stores operating over the old legacy software, and 5% from shiny website, with all the latest tech, high-availability, sub second load times and other shenanigans. Most of engineers will tend to focus on this state-of-the-art website with cutting edge technologies, but the reality is that bad design decision and poor quality of a website affects only 5% of all the company revenue stream. Don’t get me wrong, it is still a lot, but it is incomparably small to something going wrong with the in-store software, supporting 95% of revenue.
Same considerations are applicable to any system or area you work with. Imagine you work on customer order history feature in that website. Making it low-latency with great full text search is great, but not in case you have issues with the core sales order placement journey. And maybe, for such a case it is worth building simpler solution, taking less attention out from you, getting back to critical challenges, deliberately making order history slower and with just a basic order search feature.
I believe that all of this directly relates to company mission, vision and strategy.
Mission, vision and strategy
There is not much I can add about the mission statement, except of leaving here some good articles: one, two. As for the vision, you may read is as “where the company should be in X years”. Typically you may find it as “we’d like to double our revenue in 3 years”, or “take 50% of market share in region X”. Respectfully the Strategy would be a plan to achieve the vision.
Not all companies has well defined mission, or even vision, whilst most state they have strategy. Software Architect typically operates at the Tactics level, so good understanding of the Strategy will help to build a good understanding of the Why question.
In large organisations usually it’s an Enterprise Architect’s role to run the business capability mapping exercise, unpack business strategy into the IT one, get the knowledge about it and share it to the rest of the department. However sometimes company simply doesn’t have such a role or dedication, so a gap in understanding of the strategy and it’s execution emerges.
I believe that a good Software Architect should ask enough of questions, to clearly understand how his actions are helping to execute the strategy, and be able to understand his areas of focus by himself, not only when manager says to work on a particular project or task.
Nonetheless it’s not a primary role of an Architect to validate and rubber-stamp the priorities, it’s something should be coming from the business.
Enabling the business to make technical decisions
How can one guarantee its focus is at the most valuable or critical place? Every initiative or project should be tied to company goals, and have KPIs attached to it to measure the success. Sometimes metrics are not explicit, but there is always a principle how’d contribute to the success of the company.
I believe that the best thing any Software Architect (or Engineer) could bring to the table is providing their knowledge to build the most effective software under given circumstances. Understanding the criticality, time to market, longevity and resource availability, a good architect may find the best solution to address all the needs and constraints, addressing downstream impacts and highlighting risks.
At the design phase an Architect should have lots of stakeholders, which in turn behave according to their believes and targets. These could be senior technical management, business representatives, project managers, engineering team and their representatives, end users, owners and users of downstream systems and so on.
All of them talk different language, user different terminology, but most importantly some of stakeholders doesn’t have technical background and are bound to the business domain.
So how one should make decisions? Personally, I’m a strong believer that any technical decision could be described not only in non-technical terms, but also in terms of business capability impact.
Example: Consistency vs Availability
Consider a typical choice most architects face nowadays: a choice between the Availability and Consistency (referencing the CAP theorem) within a distributed system environment. I strongly believe it is possible to outline trade-offs in a way, so business representative could contribute.
Let’s get back to the Retail company we talked earlier. Assuming they launch a new digital proposition having Point of Sale system in offline stores, and a new eCommerce website to be built on top as a standalone application. Immediately one may highlight a potential race condition concern, when both systems simultaneously would try to sell the same product, leading to inconsistencies and unhappy customers.
So how should the stock inventory figures be synchronised between these two systems? If this case doesn’t look too complex for you imagine company runs global, having multi-region deployments but a single physical distribution centre. How to choose between consistency or availability: implementing a form of a distributed transaction (e.g. SAGA, etc) or letting inconsistencies happen?
What would be the business impact, in case oversale happens due to consistency break? Stock figure may become negative, but the most impactful that some colleague would require to let some customer know their order was a mistake, leading to one of the following options:
- Longer fulfilment lead time, while stock gets replenished.
- Proposition of buying another product, maybe with a discount.
- Cancellation of an order, with returned payment and lost revenue.
None of the above looks good, but it’s just a manual process mitigating the risk of oversale happening due to an inconsistency. Now let’s compare it to the trade-offs entailing the second option: strong consistency with a distributed transaction implementation. The trade-off here is quite obvious, both systems would be tightly coupled at runtime, meaning when one system goes offline — another would be affected too. Potentially leading to a halt in the mission critical business capability — ability to sell.
There are myriads of options to address this specific case, but the point I would like to make here is that I strongly believe that every software design decision could be described in such a way so non-technical person would clearly understand trade-offs and provide steering, reasoning about the risks and implications.
I find it quite typical, that business would choose to oversale, as it enables a chance to increase the revenue. And mostly strong consistency guarantees are not required, simply because it may lead to delays in customer service or complete unavailability of the system.
Enabling the team
As a person much more exposed to strategy, understanding of the business and capability criticality, a good Architect should share their knowledge to the engineering team on a daily basis. Every design or decision should be backed by the Why question, so that teams would be clear on what’s valuable. Every low-level decision to be made by the team should have a business input justifying it.
While everybody tries to follow the Open-Closed design principle, the reality shows it‘s quite typical for an engineering team to refactor the code frequently. This is one of the great places, where an Architect may provide vision whether a particular piece of software implements business critical capability with high non-functional expectations, or just a support function where reduced guarantees are acceptable.
Another great topic a good Architect could bring to the table is understanding of the expected speed of change for specific capability. Support functions and processes are rare to change and sometimes it’s significantly faster to replace the whole piece of code implementing such, instead of improving. If that’s a case, it is justifiable to not making it perfect in the first place, reducing the effort building it.
Such steering could be done not only at the point of decision to be made, but also as a well-written set of explicit non-functional requirements. In the business-led company I’d say this is one of the most under fulfilled task, to derive clear technical metrics and SLAs from business expectations.
A good set of non-functional requirements should cover all the aspects, including longevity, security, maintainability, scalability and others. I believe this can define the principles behind every decision, and steer away from sub-optimal ones at an early stages.
Takeaways
For all the Architects I’d recommend the following:
- Ensure you’re working not only with How, but also have clear understanding of What, with at least some clearance of Why.
- Ensure you can tell whether a particular feature is mission critical, business critical, or more like a support one.
- Ensure the most of your attention is spent around critical and valuable capabilities, reducing the focus on non-critical and non-valuable.
- Ensure you operate with non-technical trade-offs when making decisions, backing the decision with risk mitigation plans.
P.S. Please, leave your feedback in comments. This helps me to find a direction for the next posts.