Architecture Essays
Why do we need information technology?
Let’s begin at the beginning and check why we need IT and this article at all.
Humans do many things for survival, growth and reproduction. Hunting, gathering, farming, mining, converting raw materials into goods, transporting goods for use and exchange, creating and using money, playing, and entertaining — these activities have been going on for about two million years. Yet, the computer age started around 1945 and is less than a century old! So we know we can survive without computers, software and IT systems.
Information Technology seems tremendously important in its ubiquity and economic value. But when we see it from an evolutionary perspective, it’s only a tool, like a plough, hammer or spanner. It has no intrinsic value, like stones, trees, iron or wheat. It helps us shape material things in our environment to get much more out of them. The historical sequence of tool technologies has been — mechanical→hydro-pneumatic→electro-magnetic→electronic→digital. Binary-based programming developed almost simultaneously with electronics.
So what does Information Technology do? If we think about it for more than two seconds, this is not a trivial question.
What does the IT tool do for us?
There are three ways computers, software code, applications, and electronic networks deliver value.
Execute —These are the core capability layer systems that directly make life better for humans, e.g., the communication systems involved in making a mobile phone call.
Control — Systems that operate and manage the execution layer, e.g., the telecom company’s advertising, sales, billing, payment collection and operations systems.
Direct — Systems for decision support to keep the execution layer stable or growing, e.g., the telecom company’s reporting, Business Intelligence, and planning systems.
These three things are provided in every type of IT you can think of at every level. Consider something like a printer to a complex shipping company, and you’ll see the three functions in every discrete digital part.
The problem of IT’s disconnection from reality
Computer programs grew in complexity along with human activities. It became increasingly difficult to represent the real world and its rules and events in continuously unrolling lines of code in single files, even with conditional and logical constructs, loops, etc.
This gave rise to the idea of Object Oriented Programming, a giant leap forward in modelling. Simula and Smalltalk were born, C evolved into C++, and Java entered the fray.
These constructs helped deliver decent computing software for business and continue to do so underneath many modern “web” languages and frameworks.
However, a problem emerged — a growing disconnect between the real world and the world of software programming. This divergence negatively affected software execution and control. Logical errors, performance issues, and difficulties in change became common.
Two solutions arose to address this problem —
- The field of IT Architecture
- Domain Driven Design
The rise of the IT architecture discipline
Since humans have dwelled in caves, they have represented the world as objects, relationships and events through language and drawing. These models of the world helped humans hold and consider complicated things outside their minds, communicate, discuss, create new ideas and build things. This is essentially architectural thinking. We jokingly say, ‘God in an architect’.
With the need for large-scale infrastructure, religious buildings and workplaces, the profession of civil architecture developed and thrived.
IT architecture as a discrete way of thinking and solving problems crystallised about 25 to 30 years after the invention of computers and coding. In the early 1970s, Dijkstra and Parnas proposed that a system’s structure has a real impact, and we need to design it. The IEEE was a catalyst for software architecture standards and methods. In the 1980s and 90s, other disciplines of architecture arose to deal with the growing complexity of businesses and information technology. The broad sequence was — application architecture, information architecture, integration architecture, enterprise architecture, business architecture, and infrastructure architecture.
IT architecture as a tool serves the following purposes —
- Links business with software and technology
- Breaks down the overall problem landscape into manageable chunks
- Converts functional and quality requirements into a high-level solution
- Provides a means of communication between all stakeholders
- Provides a relatively stable model through which business and software changes can be managed in an orderly manner
The rise of Domain-Driven Design
Since the 1960s, several frameworks have developed with patterns that help software designers and developers conceive components and interfaces quickly.
These include mainframe computing, Unix-like, client-server, COM/DCOM, MVC, MVVM, MVP, VIPER, SOA, microservices, etc. You’ll be familiar with some and can look up the others, so I won’t bother expanding the acronyms or describing them. They spanned software design and architecture, covering several domains of the latter, especially application, information, and integration architecture. We ended up with rather monolithic systems on one end of the spectrum to swarms of atomic software at the other.
The world progressed fast on the back of Information Technology, which is mostly computer software, and these software design paradigms served us well. But there’s always the matter of evolution, so we kept our minds open and challenged ourselves to find better ways. An excellent option emerged in 2015 for creating optimum IT programs — Domain Driven Design.
DDD aims to deliver high-quality software through domain and IT specialists co-creating models that understand, refine, and apply expert knowledge of the enterprise’s workings.
DDD is a technique so natural and obvious that it will stand the test of time and changes in human activity.
The ideas of DDD
There are excellent books and papers on DDD. Here are three examples, starting with the definitive text from Eric Evans.
For the purposes of this article, here are the main ideas of DDD, in short, that assist architectural thinking.
- Domains, Sub-domains, Core Domain — A domain is a distinct sphere of activity and knowledge characterised by its specific language, e.g., Marketing. A sub-domain is a part of a domain focused on a subset of activities, e.g. Campaign Management. A Core Domain is the domain or sub-domain with the highest return on investment for the enterprise, e.g., eCommerce.
- Ubiquitous Language — A shared language and semantics developed together by domain and IT experts and led by domain experts. E.g., shipment, itinerary, accrual, invoice, bill, post, notify, etc.
- Entity and Value Objects — Entity Objects represent unique things in the domain that can change, e.g., client, product, shipment, invoice, etc. Value Objects represent pure quantities and measurements that describe Entities, e.g., age, time, count, weight, etc.
- Bounded Context — A conceptual boundary within which a domain model and its Ubiquitous Language are applicable. E.g., Supply Chain, Customer Service, Finance, etc.
- Events — Significant happenings in the domain or sub-domain. E.g., load, dispatch, deliver, etc.
- Context Mapping — Identifying the relationships between Bounded Contexts for developing interaction interfaces and artefacts. This article has a good introduction.
- Service — A stateless operation that fulfils a domain-specific task. E.g., authenticate, getSparesList, etc.
The Confluence of Architecture and DDD as Domain-Driven Architectural Design (DDAD)
When I learnt architectural thinking for the first time around 2002, we students struggled most with getting the cohesiveness of our functional components right.
Should we begin with related data to decide the components and sub-components? Or should we group technical functions? Or business functions? Should performance requirements dictate the placements?
We did our best and came up with something that, in real projects, turned out only half right in the first iteration. We improved with experience, but it was never easy.
We often looked downward and inward towards software engineering to provide a way of thinking that could reflect the world.
I came across DDD in 2017 and immediately felt a ‘wow, what elegance and power!’ moment.
At first, I propagated it to the software designers and Business Analysts in my network. It soon became apparent that it was entering more and more into my architectural thinking too. But DDD was aimed at software engineering rather than architectural thinking. And it didn’t go beyond application architecture into business, information, integration, infrastructure, and enterprise architecture.
Still, I began using its concepts in my interviews with business stakeholders as an Enterprise Architect and End-to-end Solution Architect. For the information model and integration components, I encouraged the specialists in this area to work closely with the business domain experts and software designers to adopt the nouns and verbs of the Ubiquitous Language (UL) in their designs.
DDAD Outline
DDD is aimed at software engineering, but my interest is in architecture, and my conception of DDAD is a derivative of DDD.
Last year, I extracted the architectural aspects of DDD into a separate stream of thinking. I drafted a practical guide that mapped DDD terms to Architectural terms and outlined a Domain-Driven Architecture Design (DDAD) framework. DDAD aims to enable —
- Capturing Domain Knowledge as Business Use Cases using UL
- Stating Architectural Problems as Domain/Sub-domain Needs and Wants
- Making Architectural Decisions that model sub-components, components, systems and interfaces based on cohesion, loose coupling and reuse that comes naturally from Domain Knowledge
- Architecture modelling and diagramming using Domains, Sub-Domains and UL
- Applying and conveying the DDAD model for all architectural aspects and the high-level software design
At a high level, DDAD also aims at identifying the paradigms that are deprecated or subsumed by it.
Please look out for the DDAD Primer in part II — an upcoming article on Medium and LinkedIn.
End Note
If you are a software engineer, learn and adopt DDD. If you’re an architect, understand DDD, then learn and apply DDAD. Together they will delight your customers and you.
Connect with me: 
