Architecture Guidance

The organization I work for maintains a number of internal forums.  Like any forums found online, they’re a repository of information ranging from basic topics to advanced ones.  Occasionally though, philosophical debates spring about about different technologies or the direction of any one of our products.  One such debate emerged this past week about the role of Java within our organization and then ballooned into the broader issue of architectures influence (architecture being the group of people responsible for core functionality on which a number of products are built).  One quote I found very interesting,

"I have come away with the distinct impression that the framework will not force a technology choice on the product teams."

I have found two ways to interpret this.

1) I don’t want to have to learn a new technology because it will take significant effort (ie company time not spent improving the existing product)

2) I want to pick the direction my product goes in

Both are valid arguments and deserve consideration but reflect underlying problems.

As a member of the architect group responsible for our client application, the above comment reflects a perspective I found myself neglecting to appreciate.  My short experience has shown me that it’s very easy to sit atop the ivory tower and declare the next technologies on which our products will be built.  Changes in direction can be justified by the many benefits of one technology or another.  I’ve seen myself and others think about a certain technology and say, “Wow, there are so many good things about this and everyone is going to be just as excited about it as I am.”  The reality is that technology changes at the framework level of a product are significantly more difficult at the product level than at the framework level.  Product’s entire implementation will likely need to be changed.  They’re the ones who use the framework and push it in places architecture didn’t anticipate (no, we can’t anticipate everything, though we try very hard).

The question then becomes how do you evolve your application and get buy from the teams who are using your framework?  Applications need to evolve, they need to maintain a competitive advantage and they can’t do that by going with the status quo.  Technology changes very rapidly in the software world and by no means can an organization jump on board with everything.  But it cannot stay with anyone for too long.  Not only will they lose competitive advantage against similar products but they will have a hard time attracting new developers.  Developers want to be working with the latest and greatest. To keep those developers happy a company has to be willing to bite the bullet and jump forward otherwise they risk losing the ability to attract new talent.

Further on that point, technology doesn’t change just to change.  There are tangible benefits as well.  Quality of code (unit testing), appearance of the product (RIA and presentation frameworks) and the ability to adapt to changing business requirements (DI, IoC) are all areas of major focus in emerging technologies.  But the problem of how to get adoption from other groups still remains.

This is probably the part where the second interpretation of the above quote comes into play.  Buy in from all stake holders must be integral to any technology shift.  This becomes very difficult though when the different stake holders want very different things from an architecture group.  We can only make a framework so decoupled to allow for maximum reuse of components.  At some point we need to pick a direction and some people won’t like it.  The point of an framework is to minimize a lot a the leg work required to make an enterprise application work.  This is much more efficient than having each product implement their own, I don’t think anyone can argue with that. 

Unfortunately I feel like I’m spinning my wheels here.  We’re now back to the architects on the ivory tower declaring, “though shalt use ….”  The best we can do is get everyone’s input and make the best judgment we can that gets the most gain for the most people and the least headache for the fewest number of people.  It’s unfortunate to live up to the stereotype but it’s somewhat understandable where it comes from, it is the nature of the beast.  At the very least, an architecture group taking a strong stand is better than taking no stand at all.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s