Summary
Is it valuable for an enterprise to adopt a <i>Reference Architecture</i>? If so, how should that RA be used?
Advertisement
Recently I was consulting for a firm that stressed their adoption of a Reference Architecture. The RA was not an uncommon one. It was based on Webshphere and EJB, and made use of a number of proxies and shunts to connect their web servers to a DB2 back-end.
In my talks with them I pointed out that I prefer to allow new applications to grow into the reference architecture rather than just assume that it will be used. I told them that I wouldn't start out using a database, or EJB. I'd start out doing the simplest thing I could and, over time, let the growing application force me into adopting architecture elements. If I got the application finished before I had to adopt the entire architecture, then that would be a good thing.
Some of the architechts were, shall we say, aghast. They made some good points. One of the best was that if you have a reference architecture that everyone follows, then all programmers will be able to understand every application. At least there would be common structures that they could follow.
While I accept this as valuable, I reject the notion that a reference architecture should be followed by default. I think a reference architecture must be tested and proven for each new use that it is put to. And I think the best way to accomplish that testing and proving is for each new application to be allowed to evolve from very simple beginnings. If those new applications start requiring architecture elements, then the developers have the choice of using the existing RA, or of using something different.
Clearly using a different architecture is risky. No development team would undertake it unless they were strongly motivated. Yet if such motivation exists, and if the developers find a better solution, then the enterprise will benefit from the new knowledge. However, if all application must adopt the RA from the outset, then the opportunity for this benefit is squelched.
My experience is that RAs are big and cumbersome impediments to simple development. Instead of writing one or two classes to get a job done, one must write one or two dozen, spanning different groups, different disciplines, and different languages. One must adopt tools and infrastructures that have long learning curves, and that make automated unit and acceptance testing difficult if not downright impractical.
My advice to the industry is to allow reference architectures to constantly evolve, and allow them to be challenged and tested with every new application and every new change.
One of the best was that if you have a reference architecture that everyone follows, then all programmers will be able to understand every application.
Well, that's a nice theory. But (as I'm sure Uncle Bob really agrees anyway ;-) ), I think it creates a false benefit.
What happens when the programmers have to repeatedly shoe-horn requirements that don't easily fit the RA into work-around hacks? The next guy who comes along thinking that he knows the app because he understands the RA is in for a rude surprise.
It is the core fallacy of BDUF thinking: "if only we could specify everything ahead of time so that everyone must conform, bad things won't happen."
Much better to achieve understandable applications by rigorously simplifying and clarifying them so that someone coming along really can figure them out without knowing where all the kludges are buried.
Maybe reference architecture are more useful in organizations that have a lot of less-experienced/talented developers that cannot be trusted to make design decisions--in other words, managing for the lowest common denominator. This way they can build features without having to make a lot of risky decisions or taking up the time of the more expensive staff--they can just follow the formula. You probably don't often end up with the optimal solution to any given problem, but you also don't end up with as many disasters.
Not that I think hiring bad developers and closely managing them is a good way to run a development organization, but it often seems to be the reality!
Maybe reference architecture are more useful in organizations that have a lot of less-experienced/talented developers that cannot be trusted to make design decisions
Another common theory. But I think it falls down too. ;-)
Those inexperienced developers are the ones most likely to code themselves in hack-around nightmare confronted by a fixed RA they don't really understand.
Much better to seed your team with the experienced "architects" who can then lead by example. The newbies' mistakes can be noticed and fixed sooner, and they will thereby learn faster and more forcefully.
Hoping that they will be prevented from harming themselves by dumping wisdom on them from on high seems to me to be counter-productive.
> Much better to seed your team with the experienced > "architects" who can then lead by example. The > newbies' mistakes can be noticed and fixed sooner, and > they will thereby learn faster and more forcefully. > > Hoping that they will be prevented from harming > themselves by dumping wisdom on them from on high > seems to me to be counter-productive.
I'd go even further to say that any "architect" who can't or won't code alongside the serfs slaving to build one of his temples isn't worth his salary. Not only do the "junior programmers" learn from the architect, the architect learns from the struggles of other programmers what design decisions create implementation problems, efficiency bottlenecks, and maintenance nightmares.
As an analogy: Every so often buildings have structural problems because the architect either didn't consider the difficulty of implementing the design, or weren't on-site when builders substituted an easier and more familiar (but structurally less sound) technique for the one he anticipated. In the infamous Kansas City Hyatt Regency disaster, a triple-decker bridge designed to be supported by one-piece support rods running through all levels was actually supported by multiple rods, each hanging from the previous level; 114 people died. Recently I heard of another building (can't recall the name) which for obscure but then-sensible reasons had its main supports in the center of each outer wall instead of at the corners. The architect discovered several years after construction that the diagonal load-bearing supports were bolted rather than welded, and in a severe storm the bolts could snap ...
Not everyone builds software where bugs can cause death. Nevertheless, it's sobering to wonder whether that brilliant architecture could lead to a Big Ball of Mud when turned over to uninformed or less-skilled programmers.
From what I have experienced, an RA usually makes easy things easier and hard things harder. If can find the breaking-point between easy and hard, the decision whether to follow an RA is easy, and so will be the work.
> In my talks with them I pointed out that I prefer to allow > new applications to <i> grow into</i> the reference > architecture rather than just assume that it will be used. > I told them that I wouldn't start out using a database, > or EJB. I'd start out doing the simplest thing I could...
There are two implied assumptions that may not always be true: a) That the simplest thing is to start from scratch every time. Perhaps some up-front design might suggest that the simplest starting point for a new system for a customer is the customer's existing RA. b) That, given an existing RA, a new system can be "allowed" to grow into it. Given XD's central mantra of always developing the 'simplest' thing that could possibly work, the chances of a system growing into a predefined RA are surely minimal.
"...The RA was not an uncommon one. It was based on Webshphere and EJB, and made use of a number of proxies and shunts to connect their web servers to a DB2 back-end...."
What is commonplace here is the fact that this wasn't an architecture at all, but a bag of premature tool choices.
> b) That, given an existing RA, a new system can be > "allowed" to grow into it. Given XD's central mantra of > always developing the 'simplest' thing that could possibly > work, the chances of a system growing into a predefined RA > are surely minimal.
since uncle bob is typically more pragmatic than dogmatic, i suspect that he believes that the RA should also be "growing into" the new application(s). (putting more words in uncle bob's mouth) both sides, enterprise applications and the RA, should start from nothing and evolve toward a symbiosis that adds value to the enterprise. in effect, applying XP mantras to even RA's.
XP requires customers. in this case, the customers are the operations support and the enterprise application developers. the name "reference architecture" implies big-headed-developers-with-power developing for lowly serf coders. but the lowly operations support guys are also on the receiving end of this too.
now that i think about it, the name is pretty darn unattractive. i doubt i'd feel great about being oppressed by an RA. it might be more marketable to call it "Cheap Highly-Available, Project Management, QA, Infrastructure and Support". ... (word from our humble architects) "for a nominal departmental fee, you too can share the quality service guaranteed by your local Websphere, EJB, DB2 proxy/shunt webserver back-end." ... your application doesn't have to use it but then again, you have to pay for your own infrastructure and answer your own support calls.
> b) That, given an existing RA, a new system can be > "allowed" to grow into it. Given XD's central mantra of > always developing the 'simplest' thing that could possibly > work, the chances of a system growing into a predefined RA > are surely minimal.
since uncle bob is typically more pragmatic than dogmatic, i suspect that he believes that the RA should also be "growing into" the new application(s). (putting more words in uncle bob's mouth) both sides, enterprise applications and the RA, should start from nothing and evolve toward a symbiosis that adds value to the enterprise. in effect, applying XP mantras to even RA's.
XP requires customers. in this case, IMHO the customers are the operations support and the enterprise application developers. the name "reference architecture" implies big-headed-developers-with-power developing for lowly serf coders. but the lowly operations support guys are also on the receiving end of this too.
now that i think about it, the name is pretty darn unattractive. i doubt i'd feel great about being oppressed by an RA. it might be more marketable to call it "Cheap Highly-Available, Project Management, QA, Infrastructure and Support". ... (word from our humble architects) "for a nominal departmental fee, you too can share the quality service guaranteed by your local Websphere, EJB, DB2 proxy/shunt webserver back-end." ... your application doesn't have to use it but then again, you have to pay for your own infrastructure and answer your own support calls.
> I told them that I wouldn't start out using a database, > or EJB. I'd start out doing the simplest thing I could > and, over time, let the growing application force me into > adopting architecture elements. If I got the application > finished before I had to adopt the entire architecture, > then that would be a good thing.
Reference Architecture in my mind goes farther than picking to use EJBs or a Database.
As Martin Fowler points out in his Patterns of Enterprise Application Architecture book, there are certain things that you want to go ahead and incorporate into your architecture if you know you are going to use them.
I would venture that it is very, very rare that you don't know whether you are going to need a database or not.
As far as EJBs go, I think it depends. If you are using Stateless Session beans to create a service layer for your application, again I would venture that it is very rare that you don't know whether you are going to have more than one type of source (e.g. a Web server, some dataload scripts, and a GUI application) hitting your application, and thus requiring a service layer. If you know you are going to need a service layer, it is probably worth the time and effort to implement a service layer as you evolve your application.
Picking your overall architecture is another example. If you have programmers who understand how to write Object Models, why start of with a Transaction Script architecture.
IMHO, that is the value of experience. If you know that you are going to need a database, a service layer, and an object model, why start out with anything different.
I guess the overall point is that there are some architectural things that are just not worth trying to refactor into.
Flat View: This topic has 20 replies
on 2 pages
[
12
|
»
]
Previous Topic
