This article is also available as a PDF document.
Could businesses benefit from applying different architectural styles to design systems in different areas of the enterprise, just as cities apply different architectural styles for designing Cathedrals, Town Halls, and Bazaars? Applying different architectural styles would practically imply that when designing a system for finance we would try to focus functionality on regulatory compliance, prioritize the consistency and reliability of information over its performance, and use technical paradigms that are transactional in nature. On the other hand, when designing a self-service system for use by customers, we would prioritize usability, reliability, and performance over functional coverage, maintainability, or portability, and use a technical paradigm that is eventually consistent rather than transactional.The choice of programming paradigm (object-oriented, logic-oriented, functional programming, etc.), languages (Java, Scala, Erlang, Prolog, etc.), persistence paradigm (relational, key-value, graph, object store, hierarchical store, etc.), and hardware (highly reliable but expensive servers or somewhat reliable but cheap servers) would be derived from an architectural style. Enterprises would judiciously select the few styles most congruent with the forces in their environments, and then base architectures in different areas on the most appropriate style. Despite the diversity of styles, there would be a few common values across the entire Enterprise that would promote style multiplicity, such as a deep-rooted culture of cost consciousness or being able to identify and eliminate waste. This paper considers the characteristics of different architectural styles, the trade-offs for having multiple styles, and some considerations in implementing style diversity.
What is a Style?
An architectural style represents the set of values, principles, design criteria, and technical criteria used to build and operate systems. To illustrate the essence of an architectural style, let’s consider a couple, John and Emma, both of whom are good cooks but with vastly different styles.
Emma prefers to cook by following precise recipes. She usually spends some time thinking about the dining experience she would like for the family, and then spends some more time on the internet researching different options. After she has picked a suitable recipe, Emma likes to go to the markets to get the exact ingredients specified in the recipe. Emma’s also fond of the Saturday morning cooking shows, and sometimes writes recipes down in her journal that strike her fancy. She has a variety of kitchen equipment like egg timers and cooking thermometers that get used quite often.
In contrast, John likes cooking purely through improvisation. He usually goes to the markets without shopping lists, and returns with things that struck his fancy while he was browsing around different shops. John isn’t usually certain about what he’s going to cook until a few moments before he starts cooking. Sometimes he just raids the fridge for whatever’s available, and prides himself for being able to “just knock something up”. John’s favorite kitchen utensil is the Wok, the ideal tool for his improvisational style.
When they first started living together, they drew up a rough schedule for the days when each person would be responsible for cooking dinner. Things were initially difficult. John couldn’t understand why Emma would take so much time to cook something, or why she needed the exact ingredients for everything. At the same time, John could appreciate that once Emma was finished cooking, things were quite tasty, appetizing, and beautifully presented. Emma, on the other hand, felt John didn’t put as much care and attention into his cooking as she did. Although the dishes cooked by John did taste quite nice, she felt that things were just somehow roughly chopped up, flung into a wok, and slapped on a plate. One evening, after a long day at work, she came back to find one of John’s stir-fry concoctions waiting for her. Wordlessly, she ignored the plate on table, went to the kitchen, and cooked her own dinner. John walked up to her to ask what was wrong. Emma emphatically answered, “Why did you bother cooking? Just order take-out next time!”. They had one of their first fights after that. Afterwards, when they both calmed down, and had reflected on the evening, John began to understand that in Emma’s eyes the care and affection with which he cooked dinner for her was reflection of his respect for their relationship. He understood he had to bring some compromises to his style when cooking for the both of them, particularly focusing on his food presentation skills. Once the food began to be presented with more care, Emma also became more appreciative of his cooking. Similarly, John was able to understand Emma’s meticulous style of cooking came at the expense of waiting, and he found ways to occupy his time if it happened to be Emma’s evening to cook. Over time, they applied their different styles of cooking to different occasions. Emma would be responsible for cooking on almost all the special occasions, such as holiday meals or if they were planning to have dinner guests. John would cook on cold winter nights when neither of them felt like going out to the markets, and just using what they had in the fridge at that moment.
Understanding trade-offs make it easier to appreciate different styles
When first confronted with their vastly different cooking styles, both Emma and John initially rejected each other’s styles as ineffective, which would roughly translate to “my way of cooking is better”. Their relationship became strained, and the stronger aspects of their relationship helped keep them together. By eventually understanding the situations where one style would be preferred over another, Emma and John were able to make better decisions about their shared cooking responsibilities. This went to the extent of John being the preferred cook when limited ingredients were available or something had to be cooked quickly, and Emma being the preferred cook for special occasions like Christmas dinners. By understanding the trade-offs in specific situations, such as novelty, time, and availability, Emma and John were able to develop a rough structure for decision-making. Similarly, there are different styles of writing (concisely or descriptively), driving (hectic or steady), making presentations (marketing a product launch or giving a lecture), and speaking (precisely or concisely). Each of these styles is appropriate to a particular environment and situation, and just as seasoned practitioners in each of these disciplines are able to adapt their styles to specific situations, architects should be able to adapt a style that is coherent with the problems they are expected to solve.
The Cathedral, Town Hall, and the Bazaar
Just as there are distinct cooking styles, there are different architectural styles. Just as John was an effective cook in some situations, and Emma in others, it is important to be able to select the right architectural style for different types of problems. These styles are analogous to the styles with which urban designers and building architects design houses, offices, regions, and entire cities. If we consider the architectural styles of three prominent features of most European cities, the Cathedral, Town Hall, and the Bazaar, we can see that each one is designed with a different style. Tall, stately, and solid, Cathedrals like the Notre Dame in Paris or the Dom in Cologne are dominant features in their cities. They were built to last centuries without change as the definitive landmark around which the rest of the city would grow and prosper. Town Halls are designed to govern cities and to provide services for the residents of the city. They are built to last several decades, and they must be able to adapt with changes in the environment (e.g. prevent flooding due to changing weather patterns), commercial concerns (e.g. provide the new financial district of the town with adequate security), residents (e.g. provide an increasing population of senior citizens with better health care services), and visitors (e.g. offer travellers good hotel advice). The records stored in Town Halls, such as birth certificates, marriage licenses, and other information about residents, must be secure from those who might abuse such information. Bazaars or open marketplaces, such as a Farmer’s market or a Flea market, usually inhabit open squares, are assembled each morning, and taken down by the end of the day. Their vibrant character changes with every new day, drawing residents and visitors who are attracted by its energy.
Although each archetype seems to exist independently of each other, they also occupy common spaces. Couples who want to get married in the Cathedral must register themselves at the Town Hall. Priests in the Cathedral can organize marketplaces, such as Christmas fairs. Hawkers and Stall-owners in the Bazaar must register with the Town Hall in order to obtain a trading license. Although priorities vary in each of the spaces, people adapt when they are in the space of others. Appointments and schedules are very important in the Town Hall, and ceremonies are more important than schedules in the Cathedral. If we are to believe the movies, schedules aren’t important at all in places of ceremony given that the bride or groom is forever turning up at the last moment for the wedding. Neither appointments nor ceremonies are important in the Bazaar. Consumers show up when they want, purchase things that catch their fancy, and leave at their will. Nevertheless, when interacting in these common spaces, parties adjust their styles. Hawkers and stall-operators who sell goods to consumers must adapt to the rules and regulations of the Town Hall when applying for a permit to operate in the Bazaar. The Town Hall must understand the needs of consumers and hawkers when designing regulations for the Bazaar. Priests must understand the nature of sales and commerce if they operate a market stall in the bazaar during a Christmas fair, but the consumers also give the market-stall operated by a priest a different degree of respect than a regular stall. Hawkers and stall-operators must respect the transactional nature of payments. In all of these cases, the intersection points between different styles require adaptation between parties used to different styles.
These three strong archetypes of the city provide us with some analogies for defining architectural styles for software systems. The physical nature of cities and buildings make it easier to implicitly experience the necessity for different styles. If an Architect were to try and construct a Cathedral by applying the principles used to build a market stall, he or she would not be taken very seriously. Given the virtual nature of software systems and the inability to experience their requirements without strong domain knowledge, it is more the difficult to understand the style being adopted by a system. It therefore becomes even more necessary to explicitly state the architectural style that should be applied to designing systems for each area of the enterprise.
The structures necessary for supporting the area of Finance are analogous to the architectural style necessary to design and operate Cathedrals. Regardless of the nature of the business, book-keeping is done quite consistently. Changes, if and when they occur, are driven by external forces that apply to other businesses such as taxation laws and financial regulations (e.g. Sarbannes-Oxley). Whatever else may fail, the systems that manage finances must be extremely stable. Financial data must be highly consistent and centralized, and operations on them must be transactional. The ceremonies and rituals around taxation must never be violated, and if they are, the business must be ready to face grave peril. The most appropriate storage technology for financial data would be relational databases that are operated on highly reliable hardware. Emerging paradigms like event sourcing, provided that events are generated, persisted, and consumed reliably, are very powerful at establishing detailed audit-trails. As it is more important that the data be accurate rather than how quickly it is served, availability can be sacrificed in order to improve consistency when faced with a limited budget to realize the system.
An effective architectural style for Finance would lay the emphasis on creating systems for highly repeatable and stable processes, extremely stable data structures, and highly consistent data. Strong external forces, such as commercial and taxation regulations, define the character of the style in the financial area of a company. Architects designing financial systems would need strong respect for authority so that rules and regulations are rigorously implemented without a fragment of uncertainty. Any possible exceptions must be thought about, and handled by the system. Architects must have the traits to rigorously analyze the exact role, responsibility,and accountability of every individual who would ever use the system. They must carry strong convictions about how things are going to be like in the future, and as much as possible, bring their experiences from the past into the new systems they design. Their designs should be precise and leave no room for interpretation, and system and end-user documentation must be extremely thorough. Implementation of new systems must be accompanied by comprehensive test coverage, and any changes to the system would go through a controlled change management process. Stable standards should be preferred over experimenting with new ways of work, and changes to existing standards should be introduced with great caution.
Like Town Halls which manage the principal reason a city exists (its residents), CRM systems manage the principal reason a business exists (its customers), and we can draw several analogies between the Town Hall and CRM systems. CRM systems represent information about customers and their purchased products or services, interactions between prospects and customers with the business, campaigns and products offered by the company, and records of purchases by customers. Like Town Halls, the CRM system must be able to adapt to changes in the nature of the products offered by the business or changes the nature of the customers. Sales staff must be empowered with the flexibility to sell products and services for different prospects in different situations. If there is a rich portfolio of products, sales staff must be able to correlate the demands of a prospect with the right product offering. Customers must feel valued when they interact with the business, and be able to return for their changing needs. At moments, the business should be able to pleasantly surprise customers. Information about customers must be safe-guarded from abuse, particularly from competitors. At a minimum, the CRM system must apply legal and security regulations to ensure that the integrity of their relationship with the customer is safe-guarded.
CRM systems, above all, must be able to accommodate the complex relationship between client and provider. The bond between a customer and a business is formed through a combination of the ability to provide products that meet needs, trust built through reliability and consistency, and loyalty built through genuine gestures that the business cares about its customers, price competitiveness, and trust. In meeting needs, building trust, growing loyalty, businesses must understand both the tangible (products, offers, invoices, etc.) and intangibles (interactions, expectations, pleasant surprises, unanticipated applications, etc.) that constitute the relationship with the customer. Far too many businesses today fail to grasp the complex nature of this relationship, and reduce the entire interaction process with customers down to bombarding them with campaigns, forcing them into contracts, binding them into payment structures, chasing them up for failed payments, and reducing interactions to exceptions and issues. This industrial-age thinking, when applied to developing and sustaining the relationship between businesses and customers, can lead to the incorrect usage of the same style used to develop and sustain financial systems. Enterprises that strive for excellence must depart from this reductionist thinking, and embrace a style that appropriate respects the complex nature of needs, trust, and loyalty. Humans are far better at managing this complexity than computers, and the best CRM systems understand that their main role is to empower the humans that use them.
An effective architectural style for CRM would lay emphasis on an adaptive system that can balance product diversity and volume with brand differentiation, balance pricing complexity with brand differentiation, facilitate and record complex interactions between customers and business representatives (in sales and service), provide the means to access knowledge on products and methods, and house all of this in a secure environment so that payment and contractual information is neither abused nor given to someone who shouldn’t have it. A single architectural style for all of these areas within CRM systems is inappropriate. Interactions with customers can occur with mediums like Voice (customers calling a service number), through social media (chat, social networking sites, etc.), self-service channels like mobile applications, and through the company’s website. Traditional Interactive Voice Response systems (IVR) tend to utilize relational databases at great cost, primarily because there were very few mature options before. Ideally, recording customer interactions needs to prioritize scalability, availability, and performance over consistency. Emergent NoSQL database technologies like Cassandra are able to meet these requirements at far lower cost than a traditional RDBMS by providing eventual consistency. These distributed databases can operate on cheaper scale-out storage technologies rather than expensive enterprise-class servers at a fraction of the cost (up to 95% cheaper in some cases). Functional programming languages, such as Clojure or Scala are better at representing the fluid nature of interactions than Java, but come with the advantage of being able to run on a Java Virtual Machine, allowing enterprises to keep their existing investments in application servers and enterprise-class servers. On the other hand, intersection points between the CRM area and the financial area of the business, particularly with payment and contractual information, necessitate the usage of transactional paradigms that value consistency and availability over performance. In order to achieve higher performance, more processing power and memory can be utilized by purchasing enterprise-class servers. Traditional Service-oriented Architecture (SOA) architecture coupled with data models that guarantee transactional controls can be built using stable programming languages like Java. The development of an architecture for Interactions and Payments requires the development of two different architectural styles. It is therefore important to develop multiple architectural styles within the CRM area, ensuring that the solution structures embrace the styles of the workers in the areas, and keep strong cost-consciousness through understanding how programming choices affect the selection of repositories and hardware. This is a significant shift from the traditional layered n-tier architecture thinking, where each layer in the architecture is developed almost independently of each other.
Marketplaces, specialist shops, and large stores offer relatively obvious analogies with web-shops and e-commerce solutions. Consumers first come to shops out of curiosity (perhaps by a campaign that has caught their fancy), necessity (a need to purchase a product or service), perceptions of value, and hearsay (someone has told them something nice about the shop). Consumers have the freedom to browse around the shop, select things they might want to purchase later, ask for assistance should they choose to have it, receive consultancy about products from staff, and make purchases. The most interesting shops are those where the shopkeepers have good knowledge about the products and services they are selling and are able to give us informed advice. The most annoying ones are the places where we hear “I don’t really know much about the products, I just work here.”
Effective web-shops balance the limitations of a virtual experience with a wealth of information about products. Consumers must be able to find their way easily around the web-shop, get information about products (as little or as detailed as they want), speak to experts about advice if required, and make selections for purchases. Thus far, the architectural style required is of a knowledge base than a transactional system. Until they come to the point of purchase, the consumer can look at any product, ask as many questions as they want, do research about the product, and select products that catch their fancy. Consumers are free to add anything they like to the shopping cart, and they are free to remove again if they wish. The only moment when a transaction occurs is when the consumer arrives at the check-out page, and proceeds to make a payment for the selected products.
At least two distinct architectural styles emerge from the web-shop. Scalability, availability, and performance are required to serve high volumes of consumers, and consistency should only be prioritized over the other criteria when it comes to making payments. Information about products can be served from a document-oriented database, such as a Java Content Repository or Document-oriented Repositories (e.g. MongoDB). Additions to the shopping cart, as recently demonstrated by Amazon’s Dynamo, must occur with very high availability with eventual consistency. In the past few years, browser technology has seen tremendous improvements, and is increasingly capable of handling complex presentation logic previously handled by server-side Model-View-Controller (MVC) frameworks. The web-shop’s intersection with the architectural style of finance occurs when the consumer finally arrives at the Check-Out page, and wants to make a formal purchase. The subsequent creation and persistence of an order should also be treated transactionally, in a style similar to the one applied in the Finance area. The processing of an order, however, can vary in its style of execution. Some areas of order fulfillment have a strong financial aspect, such as the eligibility of customers to purchase a product, especially if they haven’t paid in full or the product yet and plan to do so over installments or as part of a subscription. Logistics principally involves the movement of physical goods, and no two cases of transporting a package is exactly ever the same. Two customers ordering the same product may receive them from different warehouses, have them packaged differently by two different packers, have them transported by different drivers driving through different conditions, and one might be picked up for customs inspection while the other is not.Therefore the logistics of physical goods requires the flexibility to adapt to changing situations in the physical world, making logistics operations one of the most knowledge-intensive disciplines in an enterprise. The delivery of virtual goods, such as a banking or insurance product, usually does not have the same capacity constraints, but there are strict financial regulations around their creation and delivery, and the architectural style of finance can also be applied here. The delivery of virtual goods that depend upon physical entities, such as communication services delivered over physical lines, need to check on the availability of resources before providing a product, some of which can be controlled by external organizations. It is far more appropriate to treat unreliable resource, such as a physical line provided by a 3rd party, through an architectural style that is more reflective of “best effort”. The alternative is to demand a service-level agreement from an unreliable resource, treat requests to it synchronously and transactionally, and get upset when things fail. The careful and judicious selection of a case-based architectural style makes it possible to build a value-oriented enterprise.
Architecture styles require different management styles
Running a cathedral requires different skills from operating a market stall. Salesmen don’t make the best priests, and priests don’t make the best salesmen. Each area requires a particular management style that is optimal for ensuring its stability and growth. The competing values framework provides a good structure to understand the different forms of leadership, and when different types of leaders consider their teams to have been effective. The focus in hierarchical areas of the Enterprise tends to be on repeatability and consistency, leading to aphorisms like “constant mediocrity is preferable to patchy brilliance”. Leaders that are market focused will lay emphasis on competing effectively with competitors. Managers that are focused on team culture will lay the emphasis on the ability of teams to produce things together. Leaders that are innovation-oriented will insist that differentiation is established through thought leadership. Each of these perspectives are valuable, and a balanced Enterprise is able to incorporate all of these different leadership styles in different areas of the Enterprise. Encouraging style multiplicity is important, and the true test of style balance in an Enterprise can be measured by their ability to organize “Christmas Fairs”. Here each style must co-exist with others, adapting to the styles of others to find the most appropriate balance to produce a consistent result. An intersections between Finance, CRM, and Web-Shop occurs for areas like invoicing customers for subscriptions, where the Web-Shop sells the subscription, the CRM system operates the subscription, Billing generates the invoices and sends them out to customers, and Finance ensures that the payments are consistent with what’s expected. The confluence of these areas require an adaptive style that embraces the complexity of dealing with the regulations imposed by finance, the flexibility to which customers are accustomed, and the drive sales-persons have to sell products to new customers. A balanced architecture would help sales-persons maximize sales to customers that are likely to pay consistently for the subscription, provide real-time consumption information to customers so it is transparent how much they have to pay and when, and obtain payments regularly from customers.
Monothetic architectural styles in silos corrode businesses
The inability to understand the necessity for multiplicity in architectural styles usually manifests itself in one of three anti-patterns. While patterns are able to balance the prevalent forces in an environment in a positive, effective, and productive manner, anti-patterns reflect an ineffective or counter-productive resolution of forces in an environment. In Enterprises with strong architectural governance, it leads to the adoption of a single architectural style. The dominant architectural style of our times has been that of the “Cathedral”, where all applications in the Enterprise have been built on Relational Databases using a transactional paradigm for all data, and it is quite common for the “Cathedral” style to be the monothetic style of the Enterprise. IT organizations that are the least cost-effective usually have a monothetic “Cathedral” architectural style across the whole enterprise, and their ability to evolve requires heavy dis-investment in their traditional architectures. At first sight, this might appear counter-intuitive. A common myth is that architectural maturity is directly proportional to the amount of investment in systems. “Surely if a system costs a lot to build and operate, it must have a superior architecture?”
If we evaluate all architectures in the light of their ability to solve the same problems with the least waste, then architectural styles and not spend can become a measure of maturity. There also exists a tendency to manage all systems within an enterprises through the lens of finance. Although costs are a good indication of architectural maturity, they are not the only measure. “If I am praying all the time, it is likely that I am a priest. If we are talking about money all the time, it is likely we’re bankers. Otherwise, just as an occasional sermon or a daily prayer is enough for most of us, an occasional reminder about money is sufficient.”
The second course that Enterprises follow in their inability to develop style multiplicity is to resort to different architectural styles in silos or stovepipes. Each area of the Enterprise operates completely independently of each other, and utilizes an implicit style for their system design. This style is not explicitly voiced, and is perceived as the most effective way of getting things done. Rather than developing appreciation for style multiplicity, an attitude develops of “all other styles other than mine” being wrong. Anecdotal evidence of this type of behaviour can be found in the following statements: “Those guys do crazy things with Open Source tools rather than stable vendors”; “it’s not Java, it can’t be any good”; “Our stuff is so much better than what’s commercially available”, and “we built a future-proof server stack where any application can be deployed just as long as it complies to our standards”. In each of these voices, there is an underlying dogma or conviction that one way of architecture is better than another. Like the City, an Enterprise is at its most effective when it is able to develop styles in intersections, like the Christmas fair.
The final anti-pattern of Enterprises that are unable to develop style multiplicity is that of style buffering through layers. Traditional n-Tier architectures espouse the need for different layers where each discipline can do their own thing because each discipline needs to do their thing. The GUI guys need the freedom to create a wonderful user experience, but don’t want to concern themselves with the “back-end”. The Workflow/SOA Developers want to understand how to couple their services with invokers and the underlying object model. The object developers want a model that’s extensible and reasonably stable. The database administrators, usually specialists in RDBMSes, want a maintainable and normalized data model. Each group wants to work on it’s own thing in its own way, and have clear interfaces with the different paradigms. Long meetings are held between each group to discuss their perspectives, and respect is demanded for each perspective as an individual discipline. Resolution layers are required to resolve conflicting paradigms, such as the having a service-translation layer between services and objects, resolving procedural and object-oriented paradigms, and a object-relational mapping layer between objects and database tables, resolving object-oriented and relational paradigms. These layers introduce un-necessary processing overhead and accidental complexity into the overall system, and create a fragmented and waste-heavy architecture. The classical response to these new layers of accidental complexity is to “just add more hardware”. The irony of it all is that in large enterprises the co-developers of this n-tier architecture are rarely confronted with the “hardware” group. The production environments in large enterprises are usually situated in data-centers physically distant from the development team, and they are rarely confronted with the consequences of their wasteful choices. These implementation decisions are often left to vendors, who often seek to maximize their own value before that of their customer’s. The worst case scenario is when software vendor, hardware vendors, and system integrators work together in trying to maximize their own collective value rather than that of their customer’s. This results in software projects that last many months (maximizing the consulting effort of the system integrator), require the implementation of a lot of requirements (maximizing the license sales for the software vendor), and very high processing capacity (maximizing the hardware vendor’s revenue).
Clucking hens on China Eggs
Fragmentation in Enterprise Architectures in their worst form manifest themselves as “china eggs”. Ceramic eggs are used by chicken farmers to induce hens to lay eggs, and “sitting on a china egg” is a common aphorism for waiting for something to happen that never will. A china egg in architecture is an architectural representation or artifact worked upon by architects that will never be realized in practice. A china egg is typically an idealized process or data model that despite repeated attempts in several projects over several years is repeatedly ignored. The designer(s) of a china egg lay the blame of poor adoption on the organization, other people, and being far too visionary for its time. Persistent failure in the adoption of a single paradigm probably means that Enterprise Architects should consider alternative paradigms rather than dogmatically pushing a single paradigm. An architectural paradigm or model’s fit with an area in the Enterprise will ensure its adoption. Repeated failures in the adoption of an architectural paradigm or model is indicative of an underlying mis-match in architectural styles.
Style multiplicity in architecture is key for Enterprises that desire a cost-effective application landscape. By correlating leadership and architectural styles with the prevalent forces in an Enterprise, businesses can realize an optimal balance in being able to build, operate, and grow effective systems. Through the judicious application of an architectural style, businesses can drastically reduce waste and differentiate themselves from competition that continues to struggle with a monothetic style. Finally, it is through the appreciation of different styles that mature intersection points can prosper, empowering Enterprises to conduct their own “Christmas Fairs”.
I would like to thank Sergej van Middendorp, Andre Kampert, David Turner, and Ewout Meij for their insights and helping me shape this article.
This article is also available as a PDF document.
A scholarly version of this article was published in the Journal of Enterprise Architecture, February 2012, Volume 8, Number 1.