Enterprise Architecture (EA): a framework for managing the structure and strategy of an organisation, with a focus on execution. The intent of EA may be to increase organisational effectiveness, but without the right execution, it will have no
no impact. So the organisation must invest in practical application: people must know how to apply it in practice.
The business strategy derives from the organisation’s vision. It provides the driving intent behind business goals.
Business Values such as agility, and environmental factors such as the imperative of quickly responding to changes in
regulatory or economic environment, today translate into the need for responsive IT systems and digital service delivery models.
The structure an organisation adopts, decides its design, and deserves carefully thought so it aligns with its intent.
The EA framework provides the processes for translating the strategy (intent) into organisational effectiveness.
That is, in helping the organisation align to and realise its strategy. (Jager, 2023)
Evolution in Architectural Paradigms: IS to EA…
1960s to 80s: Monoliths & vendor lock-in
- software locked to vendor ecosystems (proprietary, optimised hardware-OS platforms):
- Mainframes: IBM System/370 and BUNCH (Burroughs, Univac -> Unisys, NCR, CDC & Honeywell
- Minicomputers: DEC VAX, Data General & HP
- Workstations: Sun Microsystems (running Unix)
Monolithic architectures: all application components in a single executable, on a single machine were standard.
-
Distributed computing was still nascent (Internet still in the realm of a research tool; LANs only just emerging)
- Enterprise system software was commercially licensed and costly:
- Transaction Manager: IBM CICS used in banking on mainframes
- DBMS’: Oracle, DB2, Sybase
- OS: Unix variants - IBM AIX, SCO UNIX
- Key driver: business need to automate manual processes
1990s: Distributed monoliths
- client-server model developed.
The application split into 2-3 physical tiers:
- a client,
- an application server, and,
- a database server … as opposed to the single (mainframe or minicomputer) tier of the monolith era that ran all the components on one powerful machine.
-
Processing was distributed over the network with client and server communicating over protocols like TCP/IP.
-
Networking protocols and middleware started to lean toward open systems
Driver: growth of networks of personal computers, started the pivot away from mainframes.
2000s: Internet-enabled, connected architecture and distributed computing
-
monolithic, single-machine software of the 1980s gave way to client-server and multi-tiered architectures connected by the internet.
-
XML & JSON based web services like SOAP and REST established platform-independent communication between applications on the web.
-
A decentralized user culture (forums), peer-to-peer networks (resource-sharing among small groups of machines), the growth of broadband over dial-up, introduction of Wi-Fi, made the Internet a household feature.
- 2007: shift to mobile connectivity started with the iPhone
-
Social media platforms began to flourish.
- 2000s -> Agile caught on (from the Agile Manifesto)
the way teams build software changed.- up-front design was discarded, and with it the practice of diagramming was deemed irrelevant
Enterprise Applications
Enterprise applications are very different from systems apps, embedded apps or real-time apps:
- Data outlasts the application environment (application, OS, compilers, hardware). It is
- is migrated into newer applications
- is structurally evolving to add new pieces of data without breaking old data compatibility
- is voluminous
- supports concurrent access
- Lots of screens (different representations for non-technical users)
- Integration with other enterprise applications using different schemes and ecosystem of vendor partners
- runs into conceptual (domain context) dissonance. For example a ‘customer’ might mean different things to different units
Two quotes I love from (Fowler, 2002) “‘Business logic’ - a curious term, because there are few things that are less logical than business logic.”
“Not all enterprise applications are large. Small projects often provide disproportionate value (to the enterprise).”
References
- Jager, E. (2023). Getting Started With Enterprise Architecture. Apress.
- Fowler, M. (2002). Patterns of Enterprise Application Architecture. Addison-Wesley.