Architects. Fortune Tellers. Economists.
What do all of these people have in common? They are all required to make forward thinking prognostications without having all the information. Economists regularly are interviewed on television about the future state of economies around the world, and 99 out of 100 seem to have a different answer. I’m pretty sure 98 of them are not completely correct. Fortune Tellers – enough said. And architects, particulary software architects, are often asked to help make decisions which in their judgment lead to the “best” solutions.
This post has a little to do with recent events, and a lot to do with how my thinking on architecture has evolved. I do often think a lot about how to make projects run more smoothly and achieve greater levels of success. Lots of thinking, of course, in the industry surrounds with the methodologies used by people involved in project delivery. Also even more thinking about how architecture is defined, and who is an architect and who is not. These are arguably important topics for consideration and a lot of great minds have been put to task on solving the problems. In my business, focusing primarily on application architecture and Application Lifecycle Management, means asking a very key question – repeatedly – why do most IT projects fail? Our engineering world is unlike any other out there (bridges, buildings, civil, highway management) in that, those projects achieve their desired result (yes, they may be on-time/on-budget or over), but a bridge that actually falls apart is quite rare. Sure, in IT, we go over time, and over budget – regularly. What’s even more surprising, is what we end up building sometimes doesn’t match objectives. Why is this?
Some of the key decisions – in say building a bridge – are the thickness of the material, the amount of supports. We even have a science that lets people determine how to answer those questions – physics. Many of us learn some of the basics of this in high school and college – many of us that don’t even go onto “engineering” are familiar with some of the basic concepts of physics like (“there is gravity” and “friction”). Yet, in software, knowing how to answer our analogous problems, is much more of an art than a science. Forgive the cliché, but it is likely true. Think about a little more granular discipline – such as application design – should we make this data driven, should we make these classes more re-usable? These sorts of decisions are never made by project stakeholders (or I should say probably are rarely decided by them), but are made in de-centralized fashion by architects, designers, and developers. But do we have rules of physics to help us – and do we interpret our nascent understanding of “good” in the same way? Clearly, we do not. There is no math equation that says how thick our “software steel” should be.
I have had someone – that I work with — recently tell me that “One should never do X, Y, or Z” and that “One should always install things in this fashion.” Absolute statements always spark red flags to me. Note: that might be the only absolute statement that I subscribe to. I’ll try not to recurse any further so as to not break yours or my minds here. What I realized is that this person was able to have clarity of purpose – only by ignoring a lot of big picture considerations – such as cost, time to market, and efficiency of the teams. And then I realized – we do this all the time – everywhere. Hard code this – or don’t hard code that – those are decided at very low levels on our development teams across the industry. Maybe that’s not a bad thing – I can only imagine the inefficiencies created by having everyone in management decide everything. And that’s actually what makes software hard, and why IT sometimes has a challenge in conveying its success to the rest of the business that they work for.
On some level, this seems all very basic – here’s rules to live by – don’t be blind to the world around, and don’t stick with absolutes, unless you’re talking religion and then sure, go for it. No one in our “bootcamps” for developers would ever advise the contrary. But here’s my point – whether I’m serving as a developer, an architect, or ALM consultant – rather than starting with conclusions – I start with understanding the trade-offs. We make a lot of decisions about what feels better, or seems like the right decision (you can watch for those catch phrases on your local project – everywhere). I advise people I work with – start with possible tradeoffs available, and consider why they may be valid:
- Sometimes what seems like a simple architecture – perhaps overly simple – might be actually the right decision based on business value (time to market and cost).
- Sometimes the hard coded solution is what the business actually needs
- Sometimes pushing to make more things configurable, or data driven, saves a lot in the long run.
- Sometimes a single tier application architecture is right given a size and maturity level of an organization.
Some of those statements are tantamount to heresy – but remember – the software – or architecture – or design – is not the actual goal – in the enterprise application – ever. We’re working to achieve something else entirely – it’s intangible, it’s tough to know sometimes, but it’s the concept of “Business Value.”
