Tag: Architect

As you work in requirements meetings to design software, pretend that your customer is not your customer. It turns out that this is a very easy thing to do, because it is true.

Your customer is not your customer. Your customer‘s customer is your customer. If your customer’s customer wins, your customer wins. Which means you win.

If you’re writing an ecommerce application, take care of the things that you know people who will shop at that site will need. They’ll need transport security. They’ll need encryption of stored data. Your customer may not mention these requirements. If you know that your customer is leaving out things your customer’s customer will need, address them, and communicate why.

If your customer willingly and knowingly doesn’t care about certain important things that your customer’s customer cares about—as happens from time to time—consider stepping away from the project. Just because Sally Customer doesn’t want to pay for SSL every year and wants to store credit cards in plain text because it costs less to build, it’s not okay to just agree. You’re killing your customer’s customer when you agree to work you know is a bad idea.

Requirements gathering meetings are not implementation meetings. Forbid the customer‘s use of implementation-specific terms unless it’s an absolute, or well-understood problem. Allow your customer to express only the Platonic ideal, his concept and goals, rather than dictating a solution or even using technical terms.

So how do you maintain such discipline in these meetings, which can be deceptively difficult? Remember to care for your customer‘s customer. Remember that while your customer is writing your check, you must be clear that you need to honor best practices, so that you can make what the customer really needs, not just what they say they need. Of course, this takes lots of discussion, and clarity as to exactly what you‘re doing and why.

Perhaps, as with so many things in life, this is best clarified by a poem. In 1649, Richard Lovelace wrote “To Lucasta, on Going to the Wars”. It ends with the line: “I could not love thee, dear, so much, / Loved I not honor more.”

We cannot love our customers so much, love we not their customers more.

As a seasoned veteran of software design and implementation, every architect is armed with an array of weapons they‘ve used with repeated success. For one reason or another, these technologies have found favor and bubbled to the top of our list of preferred solutions. Most likely they‘ve earned their rightful place in your arsenal by defeating fierce competition. Despite this, a barrage of new technologies constantly threatens their position. We are often compelled to lay down our weapons of choice for these new alternatives but don‘t be too quick to dismiss your trusty armaments. To cast them aside for alternatives that haven‘t been proven through similar trials is a risky proposition.

This doesn‘t mean that once established on our list of favorites a technology is granted infinite tenure and it certainly doesn‘t mean that you can bury your head in the sand and ignore advancements in software development. For each technology the time will come when it needs to be replaced. Technology moves quickly and superior solutions are on the way. As architects we need to stay abreast of industry trends, we just don‘t need to be the first to embrace fledgling technology. There‘s usually no huge advantage to being the first to adopt new technology but there can be several drawbacks.

To justify the risk involved with selecting new technology its benefits should be a quantum leap forward. Many new technologies claim such advancement but few deliver it. It‘s easy to look at new technology and see technical advantages but those benefits are often difficult to sell to stakeholders. Before you decide to blaze a trail with new technology, ask yourself how the business will benefit from this decision. If the best outcome from a business perspective is that no one will notice, rethink your decision.

Another important thing to acknowledge is cost associated to the shortcomings of new technology. These costs can be high and are difficult to calculate. When you‘re working with familiar technology you‘re aware of its idiosyncrasies. It‘s naïve to think that a new technology won‘t come with its own collection of pitfalls. Adding problems that you haven‘t solved before will destroy your estimates. You‘re far more aware of the costs involved when implementing solutions using familiar technology.

One last thing to consider is future relevance. It would be nice if we could simply identify and select superior technologies but things aren‘t quite that simple. Great technologies don‘t always win. Trying to predict the winners early is a gamble that doesn‘t yield a large payoff. Wait for the hype to die down and see if the technology settles into a space of usefulness. You‘ll find many just go away. Don‘t jeopardize your project for a technology that doesn‘t have a future.

Selecting the technologies we use to attack problems with is a large part of the software architect‘s job. Choose your weapons carefully and relinquish them reluctantly. Let your past success help to ensure future success and evolve your technology stack cautiously.