Architect

The word architect has been partially kidnapped by the technology world.  It is common to find software designers, networking experts and such with the title of architect.  I don’t think this happened yesterday.  It’s been going that way for a while.  It does get a little weird when someone asks what I do and I tell them I’m an architect.  They think I design buildings.  So I have to be careful.  Software Architect is the term I use.  That works better.

As I think of architects, I cannot help but to think of Seinfeld and the great George Costanza.

George wasn’t an architect.  But he always wanted to pretend he was one.  What attracted him to that particular profession is anyone’s guess.  He certainly held it in high esteem.

What do architects do?  Why do we need them when designing software or anything for that matter?

The first thing that should be said is that for any project there need not be a specific person identified specifically as an architect.

Visionary

To a greater or lesser extent, an architect must have a vision in mind for the product.  Whether it be a building or a software application, there must exist in the architect’s mind what it will look like, both on the outside and internally.  In the software world, the outward appearance and inner construction may be of varying importance.  Since it is possible to re-engineer a software application, the approach may be to make something that works and replace significant parts later when there is time.  How it looks to the outside world may be of greater importance in the early stages.  The reverse may also be true.  How something looks externally may be of little importance at first.

In essence, the presence of a strong architectural vision seems to be a factor in the success of most interesting—and by interesting I mean economically viable—software-intensive systems. –  Grady Booch

The architect must understand this and must layout a vision of how this will be achieved.  Ultimately success is what is important.  And the vision of how to construct the product is crucial.

Design Decisions

In the traditional sense, an architect lays out plans for something to get built.  They have to take into account a great many things.  Ultimately, they have to ensure that everything pulls together when the project is complete.  Some design decisions are critical.  Once they are made, it is extremely difficult or impossible to fix, modify or undo them later.  The right decision has to be made period.  In my opinion, this is the most important thing an architect does.

Communicate The Concept

An architect must be a communicator.  Laying out a design is important. However, the architect must still communicate that idea to those who will build the product.  If the idea and design are great, it must be implemented properly otherwise there is no point.  If this does not happen, the product will fail.  Architects use a variety of means to communicate their concept and design such as diagrams and specifications.  Who creates these specifications can vary.  In software, the specifications may be done by the architect or they may be done by one of the engineers or programmers.  In some simple cases, all these may be the same person.

The Requirements and Only the Requirements Please

While it is important to innovate, companies need predictability.  As such, the development team cannot unilaterally add features when they come up with a good idea.  Many times I have had a developer come to me in the middle of a coding phase to show me some cool way to improve the software product.  My answer is always positive.  More often, that idea cannot be implemented immediately because it would change the way users use the product.  The business expects us to deliver what we told them we were going to deliver.  We need to do that.  We cannot be throwing them new stuff that they did not expect.  Assuming you have the time and the opportunity to sell the idea to the clients so that they know something new is coming, then go ahead.  But this is a rarity.  Do what you told them you were going to do.  Then, on the next iteration, do that other cool thing, after you have had a chance to explain it to the clients.

Do Not Compromise the Core

Painting a building is easy compared to modifying the foundation of that building.

Any non-trivial application has a few layers.  It starts at the bottom and each subsequent layer is built on that.  What happens at the foundation layer is more important than the other layers.  In fact, each layer is less critical as the application is constructed.  For example, the data model is often the most crucial.  This is particularly true for application that deal in large amounts of data.  The more data there is, the more critical it is to get that part of the application right.  As time goes on, and more data is added, this increases.  I remember one application with a table containing 50 million rows.  We wanted to make some changes.  Yet we felt that this was too much data to manpulate in such a way.  That table never got any smaller.  Years later when it got to 2 billion rows, it was no longer just difficult to change, it was near impossible. However we were able to change the web application for that system quite readily.

Anticipating the Future

The architect has to understand exactly what features the application must have so that a proper data model can be built to support it.  The architect should also be asking questions about potential enhancements that might be requested later on.  This might mean building in hooks to support this feature or at least making the design in such a way that the feature can be added  without disruption of the existing design.  It is entirely possible that those who are asking for the product do not know what they will want in the future.  Planning for features in the future is not always possible.  However, it can sometimes be a good idea to put some hooks in place provided there is an understanding of where future expansion is likely to be.  In several cases, I have used a driver pattern or a plugin pattern to implement something.  I did this knowing that there might be a need for alternate formats later.  My intent is to secure the core so that it will not change and to make another driver if a different format is needed.  In one case, we had to send proprietary XML to a client.  I knew we would not be able to use that format for other clients of the service.  I designed a system where the internal representation was always the same and it was told which driver to use to create the output.  Later on, other clients came along.  We made new drivers to support them.  We never tied the system to the original specification in any way.

Make it Work Then Enhance … Repeat

If you want to build a city, first build a hut.  When you can go into the hut to get out of the rain and you can take a nap in the hut, then you are ready to build something more ambitious.  Before that happens, only think about the hut.

The same thing applies to building software systems.  Make something that works and is useful. Until that happens, don’t even talk about a myriad of features for the future.  Successful ventures are a result of smaller ventures that preceded it and acted as a springboard.

Conclusion

I intend to share more thoughts on this topic.  I will be presenting a talk along these lines at Barcamp Miami.  See you there.