Enterprise Integration Zone is brought to you in partnership with:

Arnon Rotem-Gal-Oz is the director of technology research for Amdocs. Arnon has more than 20 years of experience developing, managing and architecting large distributed systems using varied platforms and technologies. Arnon is the author of SOA Patterns from Manning publications. Arnon is a DZone MVB and is not an employee of DZone and has posted 68 posts at DZone. You can read more from them at their website. View Full User Profile

Deferring architectural decisions

  • submit to reddit
When describing the "known exceptions" to the Knot anti-pattern, I wrote the following:
Starting out on a large project, such as moving an enterprise to SOA, is difficult enough as it is. You can’t figure everything in advance; you need to deliver something – so as Nike says “just do it”. Get something done. You do need to be prepared to let go and redesign further down the road

In a comment to that post, Derrick Gibson wrote:
I have concerns about a "just do it" approach; it belies an assumption that at some point in the future the opportunity will be there to do things a "right way", whereas today time does not permit adherence to this mythical "right way".

One cannot put off til tomorrow that which should be done today. There is no guarantee of any future work to do "enhancements" or "architecture" and there is certainly no guarantee that even if there is a future project, you will be around to work on it. The next team will be starting from scratch and they will be left literally scratching their heads asking, "why did Team Alpha make this decision?"

So, if you make the first assumption that your team has to implement the best architecture it can with the time it has allotted, then will that not lead to other discussions along the way that prevent laying the seeds for this anti-pattern?

For instance, would not the use of a service bus and an approach that says each application makes calls to and receives responses from a service bus, free you from having services that call each other? Now, your services are no longer dependent upon other services or even other back-end data stores, so as new processes are defined and/or new systems are implemented (or others retired), your services remain agnostic to those changes.

This requires your service bus to have the logic which says, "this message needs to be routed here, while that message needs to be routed there." Wouldn't this approach resolve the knot anti-pattern before it ever originates?
The concrete  answer to this comment  is that service bus is one of the candidate solutions to solve/circumvent the Knot anti-pattern (as I also mentioned when I described the anti-pattern) - The question it begets  however is how do you know that the service bus is the right architectural decision for the project on the onset?! Ths question has much wider implications.

In "Who needs an Architect?" (a worthwhile reading in itself) Martin Fowler mentions that we can look at architecture as "things that people perceive as hard to change". The conclusion from that that an architect can do her work better if she doesn't impose these "hard to change things" or does that  as late as possible.
My experience is that when you start a "new grounds" project (such as moving an enterprise to SOA) there are a lot of moving parts. What I mean by that is that the uncertainty levels are very high e.g. the requirements are not set, the understanding of the technology and/or domain is partial, team is new and what not. Making a definitive architectural decision, which is "hard to change" and has a lot of effect on how you design your system and/or has substantial costs (both in licensing, training, adoption etc.) is not necessarily the right the decision. In fact, chances are you initial architectural decision will be flawed.

A phrase I heard from Ivar Jacobson once  is "plan to throw one away, you will anyway" - This is something I try to take with me and differ costly decisions if possible. Especially considering initial releases usually suffer from "time-to-market" constraints. To use a cliche - sometimes you need to go slow to go fast. By the way, this is one place where I don't agree with Uncle Bob who recently said "When is redesign the right strategy? ... Here's the answer. Never."

Like every guidance, this isn't always true. For instance, if this is your n-th similar project and you already know enough about it to say that an architectural pattern X (say service bus) or technology Y (say Hibernate) is good then, yeah go ahead and use that. You still want to consider the "cost to change" though since you can still be wrong.
Published at DZone with permission of Arnon Rotem-gal-oz, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Giridharan Rama... replied on Mon, 2009/01/19 - 2:10am

I quite agree to the content here.. Firstly, i believe that there exists a very important difference between architecture and design.. "Architecture is something that we construct for a percieved requirement whereas Design is something for a specific requirement". So there exists a realization after architecting phase. An Architecture is always with lots of assumptions.. These assumptions could go wrong (mostly it does) during later phases of the project.. if these decisions are based on the patterns (Orchestrator, Servicebus etc..) and avoid some anti-patterns (nanoservice, knot etc..) then "Cost to Change" can be kept to minimum.

But in my humble opinion, methodology also matters here.. I believe in such scenario iterative/prototyping methodology works best rather than "go ahead with what you have" type of approach.

Arnon Rotem-gal-oz replied on Mon, 2009/01/19 - 3:28am

I agree that iterative approach is good as well as the need for architectural prototyping (see for example an old post I made on the subject http://www.rgoarchitects.com/nblog/2005/12/04/SAFArchitectureEvaluationEvaluationInCode.aspx)

The point here is that if an architectural decision has a lot of cost associated with it (in terms of either implementing it or changing it later) you wat to maximize your confidence in its necessaity  before you make it. Many times this translates to doing something in the simplest thing that can possible work right now and revisiting the decision when you have more data on what's needed. 

Again if you are working on a familiar problem you may already know some of the right decisions - if you are confident that a decision is right, make it :)



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.