Architecture Styles

page 1
Indranil Bhattacharya, Coena BV.
V
i
s
u
a
l
S
p
e
c
.
o
r
g
Could businesses beneft from applying diferent architectural styles to design systems in diferent areas
of the enterprise, just as cites apply diferent architectural styles for designing Cathedrals, Town Halls,
and Bazaars? Applying diferent architectural styles would practcally imply that when designing a system
for fnance we would try to focus functonality on regulatory compliance, prioritze the consistency and
reliability of informaton over its performance, and use technical paradigms that are transactonal in nature.
On the other hand, when designing a self-service system for use by customers, we would prioritze usability,
reliability, and performance over functonal coverage, maintainability, or portability, and use a technical
paradigm that is eventually consistent rather than transactonal.The choice of programming paradigm
(object-oriented, logic-oriented, functonal programming, etc.), languages (Java, Scala, Erlang, Prolog, etc.),
persistence paradigm (relatonal, 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 diferent areas on the most appropriate style. Despite the
diversity of styles, there would be a few common values across the entre Enterprise that would promote style
multplicity, such as a deep-rooted culture of cost consciousness or being able to identfy and eliminate waste.
This paper considers the characteristcs of diferent architectural styles, the trade-ofs for having multple
styles, and some consideratons in implementng 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, lets consider a couple, John and
Emma, both of whom are good cooks but with vastly diferent styles.
Emma prefers to cook by following precise recipes. She usually spends
some tme thinking about the dining experience she would like for the
family, and then spends some more tme on the internet researching
diferent optons. Afer she has picked a suitable recipe, Emma likes to go
to the markets to get the exact ingredients specifed in the recipe. Emmas
also fond of the Saturday morning cooking shows, and sometmes writes
recipes down in her journal that strike her fancy. She has a variety of
kitchen equipment like egg tmers and cooking thermometers that get
used quite ofen.
In contrast, John likes cooking purely through improvisaton. He usually
goes to the markets without shopping lists, and returns with things that
struck his fancy while he was browsing around diferent shops. John
isnt usually certain about what hes going to cook untl a few moments
before he starts cooking. Sometmes he just raids the fridge for whatevers
available, and prides himself for being able to just knock something
up. Johns favorite kitchen utensil is the Wok, the ideal tool for his
improvisatonal style.
When they frst started living together, they drew up a rough schedule for the days when each person
would be responsible for cooking dinner. Things were initally difcult. John couldnt understand why Emma
would take so much tme to cook something, or why she needed the exact ingredients for everything. At the
same tme, John could appreciate that once Emma was fnished cooking, things were quite tasty, appetzing,
and beautfully presented. Emma, on the other hand, felt John didnt put as much care and atenton 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, fung into a wok, and slapped on a plate. One evening, afer a long day at
work, she came back to fnd one of Johns str-fry concoctons waitng 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 emphatcally answered, Why did you bother cooking? Just order take-out next tme!. They had one
of their frst fghts afer that. Aferwards, when they both calmed down, and had refected on the evening,
John began to understand that in Emmas eyes the care and afecton with which he cooked dinner for her was
refecton of his respect for their relatonship. He understood he had to bring some compromises to his style
when cooking for the both of them, partcularly focusing on his food presentaton skills. Once the food began
to be presented with more care, Emma also became more appreciatve of his cooking. Similarly, John was
Fig.1: Something Emma might be likely
to cook
Fig.2: Something John would be likely
to cook
Architecture Styles
page 2
Indranil Bhattacharya, Coena BV.
V
i
s
u
a
l
S
p
e
c
.
o
r
g
able to understand Emmas metculous style of cooking came at the expense of waitng, and he found ways
to occupy his tme if it happened to be Emmas evening to cook. Over tme, they applied their diferent styles
of cooking to diferent 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 frst confronted with their vastly diferent cooking styles, both
Emma and John initally rejected each others styles as inefectve,
which would roughly translate to my way of cooking is beter.
Their relatonship became strained, and the stronger aspects of their
relatonship helped keep them together. By eventually understanding
the situatons where one style would be preferred over another, Emma
and John were able to make beter decisions about their shared cooking
responsibilites. 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-ofs in specifc
situatons, such as novelty, tme, and availability, Emma and John were able to develop a rough structure for
decision-making. Similarly, there are diferent styles of writng (concisely or descriptvely), driving (hectc or
steady), making presentatons (marketng a product launch or giving a lecture), and speaking (precisely or
concisely). Each of these styles is appropriate to a partcular environment and situaton, and just as seasoned
practtoners in each of these disciplines are able to adapt their styles to specifc situatons, 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 distnct cooking styles,
there are diferent architectural styles.
Just as John was an efectve cook in
some situatons, and Emma in others, it
is important to be able to select the right
architectural style for diferent types of
problems. These styles are analogous to
the styles with which urban designers and
building architects design houses, ofces,
regions, and entre cites. If we consider
the architectural styles of three prominent
features of most European cites, the
Cathedral, Town Hall, and the Bazaar, we
can see that each one is designed with
a diferent style. Tall, stately, and solid,
Cathedrals like the Notre Dame in Paris
or the Dom in Cologne are dominant
features in their cites. They were built
to last centuries without change as the
defnitve landmark around which the rest
of the city would grow and prosper. Town
Halls are designed to govern cites 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 fooding due
to changing weather paterns), commercial concerns (e.g. provide the new fnancial district of the town with
adequate security), residents (e.g. provide an increasing populaton of senior citzens with beter health care
services), and visitors (e.g. ofer travellers good hotel advice). The records stored in Town Halls, such as birth
certfcates, marriage licenses, and other informaton about residents, must be secure from those who might
abuse such informaton. Bazaars or open marketplaces, such as a Farmers market or a Flea market, usually
Fig.3: Emma is now the default chef
for special occasions, and John is the
default chef for emergencies
Fig.4: Cathedrals are built to last centuries in more or less the same form,
Town Halls are built to last several decades and constantly adapt with the
changing demands in the city, and a Bazaar is never really the same from
one day to the next going up every morning to come back down the same
evening.
Architecture Styles
page 3
Indranil Bhattacharya, Coena BV.
V
i
s
u
a
l
S
p
e
c
.
o
r
g
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 atracted 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 priorites 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 arent 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 interactng in these
common spaces, partes adjust their styles. Hawkers and stall-operators
who sell goods to consumers must adapt to the rules and regulatons 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 regulatons 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 diferent degree of respect than a regular stall. Hawkers and stall-operators must
respect the transactonal nature of payments. In all of these cases, the intersecton points between diferent
styles require adaptaton between partes used to diferent styles.
These three strong archetypes of the city provide us with some analogies for defning architectural styles
for sofware systems. The physical nature of cites and buildings make it easier to implicitly experience the
necessity for diferent 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 sofware
systems and the inability to experience their requirements without strong domain knowledge, it is more
the difcult 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.
Finance
The structures necessary for supportng 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 taxaton laws and fnancial regulatons
(e.g. Sarbannes-Oxley). Whatever else may fail, the
systems that manage fnances must be extremely
stable. Financial data must be highly consistent
and centralized, and operatons on them must be
transactonal. The ceremonies and rituals around
taxaton must never be violated, and if they are, the
business must be ready to face grave peril. The most
appropriate storage technology for fnancial data would
be relatonal 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 sacrifced in order to improve consistency
when faced with a limited budget to realize the system.
Fig.5: Actvites develop between
the spaces provided by Cathedrals,
Town Halls, and Bazaar, requiring the
adaptaton of styles
Fig.6: Most cathedrals dominate their cityscapes in
a manner similar to how fnancial consideratons
dominate the commercial workspace.
Architecture Styles
page 4
Indranil Bhattacharya, Coena BV.
V
i
s
u
a
l
S
p
e
c
.
o
r
g
An efectve architectural style for Finance would lay the
emphasis on creatng systems for highly repeatable and
stable processes, extremely stable data structures, and highly
consistent data. Strong external forces, such as commercial
and taxaton regulatons, defne the character of the style in
the fnancial area of a company. Architects designing fnancial
systems would need strong respect for authority so that rules
and regulatons are rigorously implemented without a fragment
of uncertainty. Any possible exceptons 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 convictons 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 interpretaton, and system and end-user documentaton must be extremely thorough.
Implementaton 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 experimentng with new ways of work, and changes to existng standards should be introduced with
great cauton.
The Town Hall
Like Town Halls which manage the principal reason a city exists (its residents), CRM systems manage the
Fig.7: Religious buildings like the Pota;a Palace in
Lhasa can be awe-inspiring.
Fig.8: Elements of a Style for Finance
Fig.9: Htel de Ville, which has been the home of the municipality ofces of Paris since 1357, has seen some of the functons
houses remain stable and others being radically transformed.
Architecture Styles
page 5
Indranil Bhattacharya, Coena BV.
V
i
s
u
a
l
S
p
e
c
.
o
r
g
principal reason a business exists (its customers), and we can draw several analogies between the Town
Hall and CRM systems. CRM systems represent informaton about customers and their purchased products
or services, interactons between prospects and customers with the business, campaigns and products
ofered 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 ofered by the business or changes the nature of
the customers. Sales staf must be empowered with the fexibility to sell products and services for diferent
prospects in diferent situatons. If there is a rich portolio of products, sales staf must be able to correlate
the demands of a prospect with the right product ofering. 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. Informaton about customers must be safe-guarded from abuse, partcularly
from compettors. At a minimum, the CRM system must apply legal and security regulatons to ensure that the
integrity of their relatonship with the customer is safe-guarded.
CRM systems, above all, must be able to accommodate
the complex relatonship between client and provider. The
bond between a customer and a business is formed through
a combinaton 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 compettveness, and trust. In
meetng needs, building trust, growing loyalty, businesses must
understand both the tangible (products, ofers, invoices, etc.)
and intangibles (interactons, expectatons, pleasant surprises,
unantcipated applicatons, etc.) that consttute the relatonship
with the customer. Far too many businesses today fail to grasp
the complex nature of this relatonship, and reduce the entre
interacton 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 interactons to exceptons and issues. This industrial-age thinking, when applied to
developing and sustaining the relatonship between businesses and customers, can lead to the incorrect usage
of the same style used to develop and sustain fnancial systems. Enterprises that strive for excellence must
depart from this reductonist thinking, and embrace a style that appropriate respects the complex nature of
needs, trust, and loyalty. Humans are far beter 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 efectve architectural style for CRM would lay emphasis on an adaptve system that can balance
product diversity and volume with brand diferentaton, balance pricing complexity with brand diferentaton,
Fig.10: A slightly more modern town hall designed
by Willem Dudok for Hilversum in the Netherlands
Fig.11: Elements of a Style for Customer Interactons
Architecture Styles
page 6
Indranil Bhattacharya, Coena BV.
V
i
s
u
a
l
S
p
e
c
.
o
r
g
facilitate and record complex interactons between customers and business representatves (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 informaton is neither abused nor given to someone who
shouldnt have it. A single architectural style for all of these areas within CRM systems is inappropriate.
Interactons 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 applicatons, and
through the companys website. Traditonal Interactve Voice Response systems (IVR) tend to utlize relatonal
databases at great cost, primarily because there were very few mature optons before. Ideally, recording
customer interactons needs to prioritze scalability, availability, and performance over consistency. Emergent
NoSQL database technologies like Cassandra are able to meet these requirements at far lower cost than a
traditonal RDBMS by providing eventual consistency. These distributed databases can operate on cheaper
scale-out storage technologies rather than expensive enterprise-class servers at a fracton of the cost (up
to 95% cheaper in some cases). Functonal programming languages, such as Clojure or Scala are beter at
representng the fuid nature of interactons than Java, but come with the advantage of being able to run
on a Java Virtual Machine, allowing enterprises to keep their existng investments in applicaton servers and
enterprise-class servers. On the other hand, intersecton points between the CRM area and the fnancial area
of the business, partcularly with payment and contractual informaton, necessitate the usage of transactonal
paradigms that value consistency and availability over performance. In order to achieve higher performance,
more processing power and memory can be utlized by purchasing enterprise-class servers. Traditonal
Service-oriented Architecture (SOA) architecture coupled with data models that guarantee transactonal
controls can be built using stable programming languages like Java. The development of an architecture for
Interactons and Payments requires the development of two diferent architectural styles. It is therefore
important to develop multple architectural styles within the CRM area, ensuring that the soluton structures
embrace the styles of the workers in the areas, and keep strong cost-consciousness through understanding
how programming choices afect the selecton of repositories and hardware. This is a signifcant shif from
the traditonal layered n-ter architecture thinking, where each layer in the architecture is developed almost
independently of each other.
The Bazaar
Marketplaces, specialist shops, and large stores
ofer relatvely obvious analogies with web-shops and
e-commerce solutons. Consumers frst come to shops out
of curiosity (perhaps by a campaign that has caught their
fancy), necessity (a need to purchase a product or service),
perceptons 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 staf, and
make purchases. The most interestng 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 dont really know much about the products, I just
work here.
Efectve web-shops balance the limitatons of a virtual experience with a wealth of informaton about
products. Consumers must be able to fnd their way easily around the web-shop, get informaton about
products (as litle or as detailed as they want), speak to experts about advice if required, and make
selectons for purchases. Thus far, the architectural style required is of a knowledge base than a transactonal
system. Untl they come to the point of purchase, the consumer can look at any product, ask as many
questons 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 transacton occurs is when the consumer arrives at the check-out page, and proceeds to
make a payment for the selected products.
Fig.12: A stall being set-up early in the morning in
the market square of Cambridge (UK).
Architecture Styles
page 7
Indranil Bhattacharya, Coena BV.
V
i
s
u
a
l
S
p
e
c
.
o
r
g
At least two distnct architectural styles emerge from
the web-shop. Scalability, availability, and performance
are required to serve high volumes of consumers, and
consistency should only be prioritzed over the other criteria
when it comes to making payments. Informaton about
products can be served from a document-oriented database,
such as a Java Content Repository or Document-oriented
Repositories (e.g. MongoDB). Additons to the shopping cart,
as recently demonstrated by Amazons 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 presentaton logic previously handled by server-side Model-View-Controller (MVC) frameworks. The
web-shops intersecton with the architectural style of fnance occurs when the consumer fnally arrives at the
Check-Out page, and wants to make a formal purchase. The subsequent creaton and persistence of an order
should also be treated transactonally, in a style similar to the one applied in the Finance area. The processing
of an order, however, can vary in its style of executon. Some areas of order fulfllment have a strong fnancial
aspect, such as the eligibility of customers to purchase a product, especially if they havent paid in full or
the product yet and plan to do so over installments or as part of a subscripton. Logistcs principally involves
the movement of physical goods, and no two cases of transportng a package is exactly ever the same. Two
customers ordering the same product may receive them from diferent warehouses, have them packaged
diferently by two diferent packers, have them transported by diferent drivers driving through diferent
conditons, and one might be picked up for customs inspecton while the other is not.Therefore the logistcs
of physical goods requires the fexibility to adapt to changing situatons in the physical world, making logistcs
operatons 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 fnancial regulatons around their creaton and delivery, and the architectural style of fnance can also
be applied here. The delivery of virtual goods that depend upon physical enttes, such as communicaton
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 organizatons. 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
refectve of best efort. The alternatve is to demand a service-level agreement from an unreliable resource,
treat requests to it synchronously and transactonally, and get upset when things fail. The careful and judicious
selecton of a case-based architectural style makes it possible to build a value-oriented enterprise.
Fig.13: Product informaton in a spice shop in
Durban. One of them audaciously advertses the
mother-in-law exterminator.
Fig.14: Elements of a Style for Web-shops
Architecture Styles
page 8
Indranil Bhattacharya, Coena BV.
V
i
s
u
a
l
S
p
e
c
.
o
r
g
Architecture styles require different management styles
Running a cathedral requires diferent skills from operatng
a market stall. Salesmen dont make the best priests, and
priests dont make the best salesmen. Each area requires
a partcular management style that is optmal for ensuring
its stability and growth. The competng values framework
provides a good structure to understand the diferent forms
of leadership, and when diferent types of leaders consider
their teams to have been efectve. 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 competng efectvely with
compettors. Managers that are focused on team culture
will lay the emphasis on the ability of teams to produce
things together. Leaders that are innovaton-oriented will
insist that diferentaton is established through thought
leadership. Each of these perspectves are valuable, and
a balanced Enterprise is able to incorporate all of these diferent leadership styles in diferent areas of the
Enterprise. Encouraging style multplicity 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, adaptng
to the styles of others to fnd the most appropriate balance to produce a consistent result. An intersectons
between Finance, CRM, and Web-Shop occurs for areas like invoicing customers for subscriptons, where the
Web-Shop sells the subscripton, the CRM system operates the subscripton, Billing generates the invoices and
sends them out to customers, and Finance ensures that the payments are consistent with whats expected.
The confuence of these areas require an adaptve style that embraces the complexity of dealing with the
regulatons imposed by fnance, the fexibility 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 subscripton, provide real-tme consumpton
informaton 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 multplicity
in architectural styles usually manifests itself in one of
three ant-paterns. While paterns are able to balance
the prevalent forces in an environment in a positve,
efectve, and productve manner, ant-paterns refect an
inefectve or counter-productve resoluton of forces in
an environment. In Enterprises with strong architectural
governance, it leads to the adopton of a single architectural
style. The dominant architectural style of our tmes has
been that of the Cathedral, where all applicatons in the
Enterprise have been built on Relatonal Databases using a
transactonal paradigm for all data, and it is quite common
for the Cathedral style to be the monothetc style of the
Enterprise. IT organizatons that are the least cost-efectve
usually have a monothetc Cathedral architectural style
across the whole enterprise, and their ability to evolve requires heavy dis-investment in their traditonal
architectures. At frst sight, this might appear counter-intuitve. A common myth is that architectural maturity
is directly proportonal 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
Fig.15: Competng values of leadership
Fig.16: Artfcial segregaton creates unbalanced
cites. In this image from So Paulo, a favela borders
an expensive condominium complex called Paradise
City.
Architecture Styles
page 9
Indranil Bhattacharya, Coena BV.
V
i
s
u
a
l
S
p
e
c
.
o
r
g
manage all systems within an enterprises through the lens of fnance. Although costs are a good indicaton of
architectural maturity, they are not the only measure. If I am praying all the tme, it is likely that I am a priest.
If we are talking about money all the tme, it is likely were bankers. Otherwise, just as an occasional sermon
or a daily prayer is enough for most of us, an occasional reminder about money is sufcient.
The second course that Enterprises follow in their inability to develop style multplicity is to resort
to diferent architectural styles in silos or stovepipes. Each area of the Enterprise operates completely
independently of each other, and utlizes an implicit style for their system design. This style is not explicitly
voiced, and is perceived as the most efectve way of getng things done. Rather than developing appreciaton
for style multplicity, an attude 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; its not Java, it cant be any good; Our stuf is so much
beter than whats commercially available, and we built a future-proof server stack where any applicaton
can be deployed just as long as it complies to our standards. In each of these voices, there is an underlying
dogma or convicton that one way of architecture is beter than another. Like the City, an Enterprise is at its
most efectve when it is able to develop styles in intersectons, like the Christmas fair.
The fnal ant-patern of Enterprises that are unable to develop style multplicity is that of style bufering
through layers. Traditonal n-Tier architectures espouse the need for diferent 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 dont want to concern themselves with the back-end. The Workfow/SOA
Developers want to understand how to couple their services with invokers and the underlying object model.
The object developers want a model thats extensible and reasonably stable. The database administrators,
usually specialists in RDBMSes, want a maintainable and normalized data model. Each group wants to work
on its own thing in its own way, and have clear interfaces with the diferent paradigms. Long meetngs are
held between each group to discuss their perspectves, and respect is demanded for each perspectve as an
individual discipline. Resoluton layers are required to resolve confictng paradigms, such as the having a
service-translaton layer between services and objects, resolving procedural and object-oriented paradigms,
and a object-relatonal mapping layer between objects and database tables, resolving object-oriented and
relatonal 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-ter architecture are rarely confronted with the hardware group. The
producton environments in large enterprises are usually situated in data-centers physically distant from the
Fig.17: An n-Tier architecture with several layers and bufers between paradigms
Architecture Styles
page 10
Indranil Bhattacharya, Coena BV.
V
i
s
u
a
l
S
p
e
c
.
o
r
g
development team, and they are rarely confronted with the consequences of their wasteful choices. These
implementaton decisions are ofen lef to vendors, who ofen seek to maximize their own value before that of
their customers. The worst case scenario is when sofware vendor, hardware vendors, and system integrators
work together in trying to maximize their own collectve value rather than that of their customers. This
results in sofware projects that last many months (maximizing the consultng efort of the system integrator),
require the implementaton of a lot of requirements (maximizing the license sales for the sofware vendor),
and very high processing capacity (maximizing the hardware vendors revenue).
Clucking hens on China Eggs
Fragmentaton 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
sitng on a china egg is a common aphorism for waitng
for something to happen that never will. A china egg in
architecture is an architectural representaton or artfact
worked upon by architects that will never be realized in
practce. A china egg is typically an idealized process or data
model that despite repeated atempts in several projects
over several years is repeatedly ignored. The designer(s)
of a china egg lay the blame of poor adopton on the
organizaton, other people, and being far too visionary for its
tme. Persistent failure in the adopton of a single paradigm
probably means that Enterprise Architects should consider alternatve paradigms rather than dogmatcally
pushing a single paradigm. An architectural paradigm or models ft with an area in the Enterprise will ensure
its adopton. Repeated failures in the adopton of an architectural paradigm or model is indicatve of an
underlying mis-match in architectural styles.
Conclusions
Style multplicity in architecture is key
for Enterprises that desire a cost-efectve
applicaton landscape. By correlatng leadership
and architectural styles with the prevalent
forces in an Enterprise, businesses can realize
an optmal balance in being able to build,
operate, and grow efectve systems. Through
the judicious applicaton of an architectural
style, businesses can drastcally reduce waste
and diferentate themselves from competton
that contnues to struggle with a monothetc
style. Finally, it is through the appreciaton of
diferent styles that mature intersecton 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 artcle.
A scholarly version of this artcle was published in the Journal of Enterprise Architecture, February 2012,
Volume 8, Number 1.
Fig.18: Ceramic eggs are provided chickens to help
them lay eggs. Sitng on a china egg is an aphorism
for waitng for something to happen that never will.
Fig.19: Finding balance in architectural styles gives businesses the
power to organize Christmas Fares, where styles intersect in
harmony.