Archive

Archive for the ‘Clients’ Category

Corporate Technical Architecture and the Missing Link

I’ve had an obsession with technical architecture from the moment I started typing on a computer terminal back in the late 70’s. Over the course of my 27 year professional career I’ve had many opportunities to be involved in architectural discussions. In recent years I have led these discussions or been a part of the leadership.

I shouldn’t say discussion because my viewpoint almost always garners derision and fuels heated battles over the makeup and purpose of a new technical architecture. I’ve thought long and hard about the things I value in a new architecture over what other (most) architects value. I’ve struggled to articulate my vision and because I’m not as strong technically as others, I generally lose battles quickly and badly.

But I do know what I’m talking about and the other architects keep proving me right. Here’s why…

Almost every architecture team focuses on technical vision and business requirements. So if a company needs to be able to share services across a number of silo’d departments or divisions, this will require a certain type of disconnected and service-oriented architecture. At a high level, this is good and right. But everything goes haywire in the implementation because these same technologists decide to find the most technically elegant solution available.

What most architects fail to take into consideration, or simply deride any attempt to “dumb-down” their goals, is that the results of their work have an associated future-cost and could potentially damage the business. This future-cost/business risk is defined by the level of talent required to implement and maintain the proposed architecture.

The missing piece is the HR department and the market for available technical talent. When implementing a new technical architecture, the architecture team should be forced to sit down with HR personnel and look at current and projected levels of talent in the marketplace and their associated costs. If a proposed implementation requires senior level talent, then HR should be able to offer insight into current and future costs associated with that proposed implementation from a building and maintenance perspective.

“This year, the proposed implementation will cost the company $2,000,000. Maintenance costs will increase to $4,000,000 because the level of talent required to maintain the proposed architecture will likely come from the contractor world and not from full-time employees. We propose you lower the complexity of the implementation so that a mid-level developer can maintain the system. This will open availability and lower future costs to $2,500.000.”

This is the sort of conversation that is missing from every architecture discussion and needs to change. I’ve sort of realized that if I were to carve out a position in a firm, this is where I would excel. I would be able to work between HR and the technical team to monitor proposed implementations and their future costs and complexity.

It’s about time this position become standard in all mid to large corporations.

Architecting From the Bottom Up

I’m sure I’m going to steal someone’s cheese with this one, but I have very strong feelings about how systems are developed and who is involved in the process.

It’s been my experience that most companies employ someone in the Chief Architect role. This person interacts with the stakeholders to determine short and long-term technical needs, works with managers to integrate architectural change through internal product development, and above all else, let no man enter the Ivory Tower.

For whatever reason, many really smart (I mean really really smart) developers make their way into the role of Chief Architect without ever understanding who their audience is. They assume their audience is the IT Director, the Board, the principals, and all managers. It’s my contention that this is entirely wrong. The main audience for architecture is the developer. And not just any developer. I’m talking about Joe Average Developer. I’m not talking about the clock-watching consultant who tries to get his straight-eights in. I’m not talking about the workaholic senior developer who, if he (or her – no gender slights meant) doesn’t understand something, will draw his own blood in nightly rituals of self-abuse in order to gain an understanding. I’m talking about the developer that comes to work, gets handed an assignment, and wants to do a good job. They know they’re not likely to be a senior developer. They’re probably going to fork off into business analysis or project management at some point. But for now, they’re a developer. Heck, they may actually be an actor or singer who happens to know how to code. Coding pays the rent.

Back to our architect. The architect also assumes that they know what’s best for the company. They may claim they have no prejudice but believe me, they do. We all do. Out of the gate, all architects are suspect zero. We all have an agenda, we all like things a certain way. In most cases, the architect will arrange the pieces on the board that makes us feel the most comfortable. We will set out on a relentless quest to see a technical environment come to life that bears our heart and soul. We do this because we know that we can be successful in such a world. Well, actually success isn’t the motivator. That’s an illusion. We want to control our environment. That is our primary goal and in many cases, the architect doesn’t even understand their own primary goal.

However, there is another way. I see the lead architect role with four primary responsibilities.

First, there has to be strong communication with all levels. The architect should know the stakeholders, the analysts, the developers, the testers, the infrastructure staff, and the users. They should have strong communication networks with all of these people (and probably more). If you have an architect that likes to hide, boy do you have problems. I’m not talking about someone who’s digging in to get work done. I’m talking about someone that you’re never quite sure what they’re doing.

Second, there has to be a strong set of standards written down, introduced at all levels, discussed at all levels, and monitored at all levels. This may include code reviews, static code analysis, check-in policies. Developers like the freedom to write code, but they don’t like everyone doing it differently. In this respect, developers are a lot like soldiers. If you give them strict guidelines, they will find the art of their skill in being productive. They will be better for it and so will your company. If standards are given short-shrift or treated as an aside, your developers will be unhappy, less-productive, and very likely to switch jobs after the next disappointing pay-raise.

Third, all new technical requirements should be developed with all hands on deck. That means that developers should have a say in any newly developed framework. Everyone should be given the opportunity to provide technical ideas and in fact, the entire process should be presented in such a way that developers are encouraged and rewarded for their input. The less an architect listens to the developers, the more costly and time-consuming any and all new projects will become.

Fourth, and this is probably the most important. Keep it simple. I’ll say it again. Keep it simple. I don’t care if you have three PhD’s in math, engineering, or computer science. You are not going to be writing code. The developers, Joe Average Developer, are going to be writing code. So if your plan is to implement a complex set of requirements as a framework, you have failed before one line of code is written in your new framework. If you have an architect that constantly talks about object-relation mapping, object containers, dependency injection, separation of concerns, and abstraction layers, you have an architect that will create a set of middleware that no one, and I mean no one, will understand. If he gets hit by a bus, you’re screwed.

I have a rule. It’s a pretty simple rule. Take any framework or middleware or API. Grab any Joe Average Developer off the street and ask him or her to create a small data entry application with three or four related tables or a handful of related classes. It doesn’t matter if they start at the domain level or the database level. They get the same assistance that anyone else does on staff. If there’s training or pair programming in the regimen, that’s great. Here’s the rule. If Joe Average Developer can’t deliver a simple application in less than two weeks (and that’s a very forgiving schedule in my book), then you have completely failed at creating a productive and cost-effective framework. If you can’t get them to create a screen or report or web page in a few days, you’ve really messed up.

Some of the arguments I’ve heard over the years include:

“We know there are average developers, but we’re going to segregate them off into simpler jobs, like UI development.” – This is great for new development. What happens when someone has to maintain the code and all the smart people are missing?

“This isn’t that hard. I find it hard to believe that a good programmer won’t understand the framework.” – This is hubris. Don’t smart people know they’re smart? I don’t like to be an elitist but I’ve been around this business for a long time. There are many different kinds of developers, but I can assure you, only a handful will reach architect status and only a few those actually know design patterns. You can’t expect to hire all architects and senior developers. It’s just never going to work.

“We (meaning the smart people) have researched all of the requirements thoroughly. We understand all of our strengths and weaknesses. We know what’s best.” – By your divine right, you shall (cough) succeed. In the short-term maybe….let’s see your framework and code base in two years.

In summary, developers are the meat of any company that relies on computer systems for its products and services. Instead of putting one person in charge of the function of your business, doesn’t it make more sense to have everyone involved? Doesn’t it make more sense to rely on simplicity? Doesn’t it make more sense to create a technical environment that can be handed over to twenty Joe Average Developers and sustain productivity?

Or maybe you like your Ivory Tower.

The Perils of Consulting

In November of 2008, I was winding up a project at Insurance Auto Auctions. The project had gone extremely well and I was walking out with a letter from a director on how satisfied they were with my work. Over the course of ten months, I made increment changes to their development practices. They already had a very mature and strong development environment that included all the necessary hardware and software. No architect or developer could ever say that they weren’t given the tools at Insurance Auto Auctions.

After convincing management that we needed a dedicated build server, the first thing I implemented was a set of middle-ware templates that acted as a framework for accessing their databases. Not as robust as nHibernate or any of the common frameworks, but tooled for their environment without all of the extra features that either confuse developers or entangle projects with needless work. For instance, the templates I use do not have relations built-in. You have to wire them up on your own. For most traditional CRUD development projects, you rarely need more than Fowler’s Table Module enterprise design pattern anyway.

The second step was to implement continuous integration using Cruise Control .NET. A fairly common tool in the development world, created by Martin Fowler’s Thoughtworks consulting firm. This gave us immediate feedback on checked in code.

Thirdly, we went round and round about how to build the new system. Did we want to use traditional WebForms? We’re we okay with using the beta of ASP.NET MVC? Did we want to role our own MVP (Model View Presenter) framework or possibly do something else? In the end, we decided the simplest implementation, for various reasons, was to create a home grown MVP framework. Of course MVP is considered obsolete now and we saw what people were recommending, but we moved forward anyway. We felt the ability to cleanly write unit tests was a critical aspect. The downside of course was that we had to rewrite a number of HTML controls that come out of the box in ASP.NET. The out of box controls use ViewState and with ViewState off, we had to go it alone, so to speak. Luckily we had Cliff on the team. Any team that has some has brilliant as Cliff should feel blessed. I’m a pretty smart guy, but more suited to larger problem solving. Cliff has a knack for needling through really fiddly problems with a very elegant solution.

We of course got buy-in to implement unit tests in Visual Studio .NET 2008 Team Test. We installed this on the build server and after every check-in, all tests were executed and the build failed if any tests failed.

The business side worked on user stories, the developers had meetings to gain an understanding of each story, and the rest they say, is history. the development went very smoothly. By implementing all of the code in a single solution and by also implementing a nifty web.config connection string locator, we were able to execute deployments with the built-in Publish feature in Visual Studio. After dealing with complex and error prone deployment processes in the past, the project manager was deleriously happy with the new process.

We deployed the web application to several servers in a farm and after some fairly minor performance tuning, the system was deemed stable and in production.

In the last few weeks of the project, I was also working on securing my next position. This proved to be a very important decision and one that seemed too good to be true. Alas, that old saying is only the tip of the iceberg and will be discussed in Part 2.