Ben Franklin, we’re told, preferred the wild turkey to the bald eagle. It had, he argued, better character: Unlike the bald eagle it doesn’t steal food from worthier birds that caught their own, and doesn’t retreat from attacks made by birds a fraction its size.
Franklin didn’t comment on the wild turkey’s unfortunate resemblance to the turkey vulture.
In any event (you may take what follows wherever you like, but leave me out of it), the bald eagle’s noble appearance trumped the wild turkey’s noble actuality. So the bald eagle became our national symbol, leaving for the turkey status as our national meal and a decent bourbon.
What’s this have to do with IT? Franklin’s preference was architectural, driven by a set of core principles, while the Second Continental Congress’s preference was driven by superficial characteristics. (Okay, it’s a stretch. Sue me.)
Back to agile technical architecture and the role design principles play in its management. Last week’s column, you’ll recall, recommended establishing a small set of these to guide every project team that touches the company’s information technology.
To which a few correspondents politely suggested that design principles sound suspiciously like the sort of thing that looks fine on a PowerPoint slide but has little practical value.
A reasonable concern, so if you need convincing that a short list of big principles can be useful, consider the Ten Commandments. There are only (wait … carry the one …) ten of them, and of those a mere six govern human-to-human interactions. And yet quite a few folks consider them useful.
What topics should design principles cover? Not a comprehensive list, but to get you started:
- Solve each problem once vs allow multiples: For most companies this is easy. To say. Solving each problem once keeps the architecture simple and streamlined, which is why most companies would prefer to have (for example) just one RDBMS instead of several.
The challenge is deciding what makes superficially similar problems the same or different. Take development environments. It would be tempting to standardize on just one, but as a practical matter it’s rarely possible. No matter how much you insist that everything be done in (for example) Visual Studio that doesn’t mean you can avoid JavaScript. And PERL. And …
- Implementing functionality: Choices here are to either build everything to a common plan or to “buy when we can and build when we have to.” If the choice is to “buy when we can,” there are two sub-choices: Start with an integrated solution (e.g. ERP), using its modules whenever they’re a reasonably decent fit, or buy best-of-breed solutions.
- Data integration: If you build everything to a single plan, you’re done. Otherwise you’ll almost inevitably have multiple commercial systems with some degree of information overlap. If that’s the case, your choices are:
- In ERP-centric architectures, make the ERP database the hub of a hub-and-spoke data integration architecture.
- Best-of-breed application portfolios generally become federated architectures. Two sub-choices here as well: An Enterprise Service Bus or something similar that takes updates wherever they happen and propagates them to equivalent data fields wherever they live; or an operational data store, which behaves a lot like the ERP database in ERP-centric implementations — as the hub of a hub-and-spoke synchronization system.
- Or, you can choose to build custom point-to-point interfaces between systems on a case-by-case basis. It’s a bad choice, but it’s a choice.
- Business logic integration: Just as you’ll find yourself with redundant data across independently designed commercial applications, you’ll also find yourself with redundant business logic. Somehow you need to keep this synchronized, too. Your choices:
- Establish a single source of logical truth for each category of business logic, make it callable, and rip out the logic everywhere else, replacing it with a call, or …
- Keep track of the redundancies and code in parallel whenever changes are needed.
- Release currency: As mentioned last week, you can keep current or nearly so, or you can mortgage your future by waiting until you have no choice.
This is far from a comprehensive list of the subjects around which you can craft design principles. It’s to illustrate, not to fill in all the blanks.
Design principles like these guide design decisions on the part of application teams so they (1) do no harm; and (2) improve the architecture whenever they touch it.
That’s the point — that’s what makes enterprise technical architecture management agile.
And, as a practical matter, possible.
> To which a few correspondence politely suggested
WOW! You’ve *always* edited perfectly – correspondents?
Oops. Obviously not always. Thanks.
Maybe eagles retreating from smaller attackers just can’t be bothered with pipsqueaks.
Turkeys, OTOH, will attack much larger “adversaries,” like motor vehicles. Often these larger adversaries won’t bother with the pipsqueak turkey and drive right through it. Motor vehicle 1, turkey 0. And male wild turkeys are generally aggressive and just plain mean, so Ben’s choice wasn’t so great either.
I am not understanding the reasoning on why building ‘point-to-point interfaces between systems on a case by case basis’ is dismissed as a bad idea.
We don’t use ERP, and so fit fairly close to the best of breed model. I’ve never seen a system that supports an enterprise service bus, but this does not seem like less work unless the system in question already support it.
The problem is that these accumulate, the number increases polynomially, and the collection becomes increasingly hard (and expensive, and time consuming) to maintain.
I know of companies where as much as 80% of the effort in some projects goes into maintaining the interfaces and making sure they don’t break, leaving only 20% of the total investment going to creating new value.