Business Design, Knowledge & Technology (3/4)
A Guide To Business Design | Part Three of Four (3/4)
—
Business Design is a design-led approach to business strategy; in one sense, it’s a practice for capturing, visualising and communicating knowledge of how a business model is arranged and intended to operate.
This strategic knowledge becomes high-level requirements for actualising the strategy through design, products and services, customer experiences, branding, marketing, communications, processes, governance, and perhaps most importantly, digital, information and emerging technologies.
Technology is the primary driver of business change; therefore, Business Designers require technical literacy to design and transform businesses. I loosely define technical literacy in this context as:
“Having a basic understanding of software and IT architecture, including (but not limited to) infrastructure, databases, APIs, interfaces, data and common business application types (like CRM and ERP), and being capable of working effectively with technical teams and individuals, including Architects, Software Developers/Engineers, Data Scientists and Business Analysts”.
I don’t think Business Designers need to be able to write code (although it’s cool if they can), but I’d guess that most have at least dabbled with coding out of curiosity (or perhaps even necessity).
In this article, I will introduce a few technology-centric practices, tools and ideas directly relevant to Business Design.
Business Design is instantiated with technology.
Businesses are partly constructed from a web of information technologies like databases, SaaS applications, integrations, networks, business processes, and — everyone’s favourite — spreadsheets. The bigger the organisation, the more complex its IT will likely be. You can almost guarantee that bigger means far more complex and expensive to change too (more on this later).
For obvious reasons, technology architecture and Business Design go hand-in-hand. Strategic decisions about the business model are coded into technical architectures and IT solutions, from how data is modelled and stored to business logic, rules, user interfaces, web and mobile experiences, and much more.
Take Netflix as an example — its business model is directly reflected in its technical architecture, from how it charges for its service to how it delivers content to consumers. Netflix pioneered the streaming model at scale, so their engineering teams have had to continuously solve technical challenges that no other business has ever had to solve, all so Netflix can deliver their service to users. This is no small feat!
The diagram above represents Netflix’s Cloud billing architecture, part of a project to make its billing infrastructure 100% cloud-native. You can read Netflix’s business goals for Cloud migration here. It’s also worth checking out Netflix’s tech blog if you haven’t already.
Notice that what you’re looking at is a logical diagram of the architecture; it’s not code. I wouldn’t expect a Business Designer to be able to define this architecture — they aren’t technical architects, and this is complex Cloud infrastructure — however, I would expect them to understand the target architecture in this model just enough so they can collaborate effectively with technical teams to ensure the architecture is aligned to strategy.
Unified modelling language (UML).
Business Designers can connect the dots between strategy and technology — an essential capability many businesses lack. Collaboration between business and technical teams works best when we can represent business concepts and requirements in ways that are easy to understand. Models and modelling standards like UML work well for this purpose.
“Models help us by letting us work at a higher level of abstraction. A model may do this by hiding or masking details, bringing out the big picture, or by focusing on different aspects of the prototype” — UML.org.
The unified modelling language (UML) is a general-purpose modelling language intended to provide a standard way to define and visualise the design/architecture of software applications, developed at Rational Software in 1994–1996.
UML has thirteen types of standard diagrams roughly divided into Structure, Behaviour, and Interaction categories, with dedicated elements for modelling activities, components, interactions, interfaces, and more.
Above is an example of a use-case diagram. Use-case diagrams can be used to define the goals of user and system interactions, define and organise the functional requirements of a system, provide context for the requirements of a system, and define the flow and sequence of events in a use case.
We all know the quote, “A picture is worth a thousand words”. We can use models and modelling languages like UML to achieve alignment, create strategic clarity, and ultimately make faster and more productive decisions.
Data modelling.
Just as UML can be helpful in Business Design, so too are concepts from data modelling. There are roughly three types of data models:
- Conceptual Data Model: Defines WHAT the system contains. The purpose is to organise, scope and define business concepts and rules. Business stakeholders and data architects typically create this model.
- Logical Data Model: Defines HOW the system should be implemented regardless of database type. The purpose is to develop a technical map of rules and data structures. Data architects and business analysts typically create this model.
- Physical Data Model: Describes HOW the system will be implemented using a specific database system. The purpose is the actual implementation of a database system. Database administrators and developers typically create this model.
This conceptual, logical and physical modelling flow is directly analogous to Business Design. In the first phase, we aim to define the core concepts of how the business model will work. Second, we aim to expand upon these concepts in as much detail as necessary to build them. Third, we build, implement, test, iterate and deploy them.
Enterprise Architecture.
Whereas Business Design is a practice that’s focused on creating business strategy, objectives, and requirements for instantiating/operating the business model, Enterprise Architecture (EA) is a practice that’s focused on the implementation of business strategy, requirements, and objectives in data, information, systems, applications, technology, and infrastructure.
From John Gøtze:
Enterprise Architecture is an emerging profession and management practice that is devoted to improving the performance of enterprises by enabling them to see themselves in terms of a holistic and integrated view of their strategic direction, business practices, information flows, and technology resources. By developing current and future versions of this integrated view, an enterprise can better manage the transition from current to future operating methods.
When we’re designing or transforming a business, what we’re aiming to do is transition from business architecture a to business architecture b. With a startup, we aim to transition from architecture zero to architecture a. In either case, we likely want to end up at architecture d, e or f, which will require management and evolution of complex requirements, and several state changes over many years. Enterprise Architecture aims to help mediate the gaps between business goals and reality.
Above is a summary of the EA3 Cube approach for transitioning from current to future architecture. I found this diagram on EAPad, a library of Enterprise Architecture information, frameworks, and tools.
Perhaps the most prominent EA organisation is The Open Group, an Enterprise Architecture consortium offering standards, tools, and certifications for architects, data scientists, technical specialists, and trusted technology practitioners, namely the TOGAF® Standard, an Enterprise Architecture methodology and framework for developing Enterprise Architecture.
Notice the focus on requirements management in the TOGAF® Standard.
Enterprise Architecture may have lost steam in recent years, but EA as a practice is probably more important than ever. There’s an undeniable synergy between Business Design and Enterprise Architecture. Business Designers will find many valuable ideas, principles and tools in EA, and some may even want to take it a step further by getting TOGAF certified.
Business Designs as computable knowledge.
This is where things get a little more technical and weird (in a good way).
In 2016 I co-founded a company named Meaningful Technology. We hypothesised that business models could be accurately defined as axioms in an OWL Ontology and then used as a schema for unifying business data from disparate systems and databases.
The unique R&D we worked on is described in a Provisional Patent titled Ontologically-Driven Executable Business Models. The name says it all — we set out to codify a master business model as computable knowledge, then use it as the ‘glue’ for unifying and organising business data at scale. Ontologies are human-readable and machine-computable via Semantic Reasoning technologies.
Take a look at the above. Even without understanding Ontologies, you can probably follow that the individual Michael (a Person) hasChild Oriana (also a Person) livesIn USA (a Country) and hasPet Buddy (a Dog). Think of Individuals as standalone bits of data, and the Classes and Relationships as the things that describe them and give them meaning.
A Semantic Reasoner is generally used to automatically compute the classification of Individuals, based on axioms in an ontology, like this:
Person: livesIn Country (and) hasPet Dog
How does this apply to business? It’s quite simple. Businesses manage similar core data and information concepts like Customer, Address, Order, Product, Inventory, Person, Location, Unit, and Account. Customer orders Products, livesAt Address, and so on. We planned to standardise our core ontology so every business could use the same base. We knew we’d likely have to create industry-specific versions to make this feasible, which would come next.
We proposed that this ‘business-model-as-schema’ approach enabled far more productive ways of working with business data, including superior methods for data integration, systems integration, and data-wrangling for business intelligence. We had some other funky technical stuff going on with Graph Databases, which we wanted to use as the core platform database, and our ultimate goal was to make the business model itself a kind of ‘brain’ for the business. My Dad always used to say, “Knowledge is power”.
A lot has changed since we founded the company, including the name, so if you’re interested in checking it out, head over to SyncHive. Our belief in data-centricity hasn’t changed, which is the last topic I’d like to discuss in this article.
Data-centricity.
Regardless of which technologies we need or want to use for business, whether the web, machine learning, 3D printing or AR, there will always be a need to organise, store, govern, share and access data.
One of the primary drivers of creative destruction in markets is that startups can innovate and bring new solutions far quicker than established businesses. Why? Startups are unencumbered by technical debt. The absence of legacy technology, technical debt or siloed data is perhaps a startup’s most significant advantage over its established competitors.
In most established businesses, information technology inhibits innovation and transformation. As organisations grow, they deploy more and more IT systems (and spreadsheets), all of which store data in different ways and databases, and thus their data becomes more and more fractured over time. Changing any of these systems or wrangling data from multiple systems often requires days, weeks, months or years of effort, at great expense, even for relatively minor changes or access that should take no more than minutes.
In my experience, many executives and managers aim to solve these challenges by investing in ‘big-bang’ IT initiatives where the goal is to put everything into one master system. Almost every professional has experienced or heard about these big-bang IT disasters in the form of failed ERP implementations that cost tens of millions before being thrown out.
The Data-Centric Manifesto asserts that the root cause of these issues is a prevalent focus on applications rather than data. To remedy the situation (and to build modern and future businesses), we need to flip around our priorities, focusing on data as the centre of business and technology architecture rather than applications that will inevitably come and go.
Think about a bank. Any bank. In the last 100 years, the applications banks use (and give us to use) have changed several times, from pen and paper to automatic teller machines, software systems, mobile apps, and virtual assistants. In the last 30 years, we’ve seen innovation lead to entirely new forms of payment, from online purchases to P2P payments to Bitcoin.
What hasn’t changed in 100 years is the core information that a bank needs. Customers, Accounts, Debits, Credits, Addresses, Products — these are the same information concepts they used 100 years ago! Imagine a bank with a real customer who has been banking with them for 100 years. They’d want ALL of the data about that customer, regardless of which systems that customer had interacted with over the years. Data is a persistent asset. Applications are ephemeral, meaning they come and go.
Unless people suddenly stop living in homes, spending money, borrowing money, or living in general, the core data concepts for banking will not change in the next 100 years either — they’ll just expand in scope. You can guarantee, however, that technology will continue to evolve, and banking applications will continue to change throughout that time.
One of my keys to Business Design in 2023 is a focus on data-centricity as described in the data-centric manifesto. The real winners from the artificial intelligence/machine learning boom, save for those creating the platforms, tools and infrastructure to enable it, like OpenAI, NVIDIA and TSMC, are those businesses that can deploy AI/ML on unique and proprietary data. Most businesses can NOT effectively use AI/ML in this way because their data assets are fragmented across hundreds of different systems and databases, in entirely different formats, and with no end in sight to the technical mess. New businesses won’t have that problem. And that’s a BIG advantage.
Data-centricity. This is the way.
—
This brings us to the end of Part Three. I’ll show you Business Design in practice for a recent client via Imagineers in Part Four.
—
This article is one of a four-part series focused on Business Design. Part One is an introduction to Business Design. Part Two is an overview of relevant frameworks and methodologies. Part Three discusses the relationships between Business Design, knowledge and technology. Part Four is a case study of Business Design in practice.
—
I want to acknowledge Dougal for everything he taught me about Enterprise Architecture, IT, and business. You know who you are. Thank you.
—
Links & References
The EA3 Cube Approach By John Gøtze
What is UML by uml.org
What is Data Modelling? By David Taylor
Protege Pizza Tutorial by Michael DeBellis
—
