Some people seem to think it has something to do with software design patterns for large-scale multi-user “enterprise” systems. Martin Fowler’s book Patterns of Enterprise Application Architecture falls firmly into this camp. “Enterprise architecture” is described in terms of ways of arranging software for high volume, distributed, transactional systems using technologies like the Microsoft .NET platform and Java 2 Enterprise Edition (J2EE).
The patterns that appear in Fowler’s book have been around for quite some time. Patterns for storing and retrieving data from relational databases, for example – usually referred to as object-relational patterns – have been exploited in countless systems since the late eighties. PoEAA is a catalogue of some of the most widely used patterns, but is by no means comprehensive. Add to that the widely-published catalogue of J2EE patterns, some of which also appear in the book, as well as yet more patterns especially suited to .NET that are published on Microsoft’s web site, and you already have a bewildering array of generic design solutions that many refer to as “enterprise architecture patterns”.
The typical characteristics of this interpretation of “enterprise architecture” are systems that are:
- Multi-layered – the key responsibilities of accepting user input, displaying data, co-coordinating transactions and processes, modeling business data, enforcing business rules, and storing and retrieving that data (this is an oversimplification, you understand) are packaged up so that they can exist as independently of each other as possible. Why take the time to do this? Because an important goal of architecture is to make software easier to change, reuse and extend. The less dependencies there are between different kinds of logic (display, process, business), the easier it is to change one without impacting the others. Many of these patterns focus on separating architectural concerns.
- High-volume – typically enterprise systems must handle thousands of simultaneous users and deal with gigabytes or terabytes of business data. Traditional object oriented architectures, the kind we used when we were mainly building single-user desktop applications, fall apart under the strain of these huge volumes. We want to retain some semblance of object orientation – largely because it’s always good to stick close to the problem to build a comprehensible solution – but we have to be very creative about how we use resources like memory, database connections, threads, and so on.
- Component-based – back in the day, enterprise applications ran on very, very big centralized computers called “mainframes”. They were written in old languages like COBOL and Assembler. They were largely batch processors that shifted and sorted through huge amounts of data very efficiently and quickly. The code, however, was an absolute nightmare to change. Old technologies like COBOL suffer from a lack of modularity, which leads to large amounts of duplication in the code. A simple change to the structure of a record might require changes to hundreds or thousands of modules that depend on that structure. The edict of “do everything once and in one place only” is only possible with an underlying technology that allows us to package and reuse the logic effectively. Component technologies like COM, CORBA, Java and .NET make it easier to isolate logic and to reduce the dependencies between different parts of the system.
- Persistent – although there are several key kinds of enterprise application, they all have one thing in common. They need to store data somewhere so it can be retrieved, manipulated and analyzed perhaps years or decades later. If your business objects can be stored and later retrieved – even after the computer has been switched off – they are said to be persistent. A bank cannot afford to lose data, so these data stores have to be extremely robust and resilient. They also have to be capable of handling enormous amounts of data, and enormous numbers of database transactions. The most mature database technology available is relational. IBM, Oracle, Sybase, Microsoft and many others, have mature relational database products that are the engine of choice for the vast majority of business applications. It’s just a shame that object and component technologies like Java and .NET don’t quite fit with the relational model – which is very outdated and constraining. Solutions exist for mapping objects onto relational databases, and some database vendors have strong offerings in the specialized object-relational (or sometimes “post-relational”)database market space. There are also pure object databases, which cut out much of the hassle with mapping objects onto relational databases, but they are not widely used in business applications and as a result carry a high price tag.
- Transactional – as well as being able to handle large amounts of users and large amounts of data, enterprise applications have to ensure that data never gets into an invalid state. Imagine a funds transfer from one bank account to another failing half way through. The amount is debited from one account, but never credited to the other. We would wish this process to either be completed 100% or not at all. A process that must either be 100% complete or not at all is usually called a transaction. The vast majority of enterprise applications will have processes that are to some degree transactional. Managing transactions also requires that you design your software a certain way so that changes to business data aren’t committed to the data store until the transaction is complete.
- Concurrent – the data stored in an enterprise application could be used in multiple transactions at the same time. While one user is transferring funds from one account to another, another might be withdrawing cash for the same payer account from an ATM. The first user might start out thinking they have sufficient funds to cover the transfer, but before the transfer is complete the account may have been emptied by the second user. Concurrent applications need to implement policies for handling these scenarios – not an easy task when you consider the explosion of possibilities with just one account and two concurrent users. When you have millions of accounts and millions of users, concurrency needs some serious thought.
- Distributed – typically, enterprise application code doesn’t all sit on the same computer. You may need multiple computers to handle the processing load. You may need multiple technology platforms for the same application – perhaps putting your J2EE business logic on an AS/400 mid-range computer, and your ASP.NET web front end on a cluster of Windows servers. Distributing logic and data has many consequences for the design of an application. Distributed, concurrent applications are an order of magnitude more complex. The most significant impact of distributing your logic is that each node in the distributed application has to somehow share common data with the other nodes.
- Heterogeneous – enterprise applications typically involve multiple technologies and platforms. To build a web application, developers might use a programming language like Java, but may also need to use HTML, JavaScript, SQL, XML, XSLT, WAP/WML, COM+, CORBA, and so on. Gone are the days when business applications systems could be written entirely in C.
But enterprise applications are becoming the norm. Most software being built these days has enterprise characteristics, and the skills of the majority of architects and developers are just beginning to catch up. Hence, there is a high demand for people with knowledge and experience of “enterprise architecture”. When a skill set is on the ascendant, we tend to see the market going into hyper-drive. “Enterprise architecture”, in the Fowler sense, is arguably nearing the zenith of this curve.
Meanwhile, a new interpretation of “enterprise architecture” is starting to gain momentum. There are those of us who have long seen it as the “architecture of the enterprise” rather than just design patterns for high-volume software applications. Though software is undeniably a significant factor in the running of a business these days, it’s by no means the be-all and end-all. In most businesses, people are a far more significant factor. People use software to do their jobs. It is the “doing of jobs” that interests me far more than the design of the software being used to do them – if software is being used at all (and in many business processes, software still plays no part).
The new “enterprise architects” are concerned with the business information model – with or without software. An information system does not have to live on a computer. In our daily lives we create, manipulate, analyze and exchange information all the time. It’s what our brains have evolved to do, and it’s why we have such rich and sophisticated languages.
Understanding how information is used in a business allows us to exploit many of the skills and tools we’ve built up for understanding information on computers. After all, all computing concepts had their genesis in real-world abstractions. Computer science is a branch of mathematics, and logic doesn’t need silicon chips to exist.
The Unified Modeling Language is built on logical principles. At its most fundamental, it allows us to model any kind of information, as well as the processes and rules that apply to that information.
As an “enterprise architect” – one who has progressed from design patterns for enterprise software applications to the actual informational design of the business itself – I use UML more to help me visualize and communicate business ideas than I do to visualize software. This is where UML is at its most powerful – when we’re just talking about information and logic.
I see modeling as the key component of enterprise architecture – not software or design patterns. “Enterprise architecture patterns” for me are about what model we should apply to a specific problem. When I look at the famous Zachman Framework for Enterprise Architecture, I think about what models would fit into each box and about how I can join all those models together to give a more complete picture of the business.
As a UML user and trainer, I’m also interested in experimenting to see how UML can be applied in those boxes in the Zachman Framework where we might traditionally think it doesn’t apply. Typically, the higher up we go, the less UML is used. But I have discovered that UML can be applied at every level right up to the top. Indeed, the higher we go, the more useful UML becomes. This is because modeling is about abstraction, and models are at their most valuable when they are at their most abstract. I’ve found that it’s not only possible, but valuable, to model business strategy and business processes in UML – far more valuable than low-level models of J2EE components and web services. Once we’re writing code, we’re already modeling, and pictures of that code are less helpful.
The recent trend towards agile methods is demonstrating that visual modeling is less important to the development of high quality software than we thought it was 10 years ago. Arguably, the role of UML is being turned upside down. It’s no longer as valuable a tool for designing software as we thought it would be – largely because of disappointing tool support and the move away from Big Design Up Front methods. It’s increasingly becoming a very useful tool for business modeling, where the end result will be a new understanding or a new way of working – which may or may not involve software. The challenge for modelers is to let go of the world of software engineering and to explore and embrace the much wider universe of information systems in the abstract sense.
With the much-hyped Model-driven Architecture continuing to disappoint in many quarters, and with competing standards for creating software from visual models already well under development (see Microsoft’s Domain-Specific Languages, for example), it’s time we looked upwards and outwards and stopped thinking of UML as just a tool for drawing pretty pictures of our code. If we don’t, it could become increasingly irrelevant in a market that is already moving in the other direction.
© Jason Gorman, 2005.
Jason Gorman is an independent consultant, author, trainer and mentor based in London, England. He has 12 years’ experience working across a broad range of industries, applications and technologies, and specializes in business and systems architecture, agile methods, and the unification of corporate and IT strategy through simple, lightweight and rigorous techniques. His web site, parlezuml.com, is currently the most popular UML training resource on the Internet, according to alexa.com, and his tutorials have been used by over 130,000 people since 2003.
Further Reading
- Patterns of Enterprise Architecture – Martin Fowler
- Describing the Enterprise Architecture Space – Microsoft
- Core J2EE Patterns
- The Zachman Institute
- UML for Managers – Jason Gorman
Comments