a) didn't think those things would happen
b) even if they did happen he'd be fine for the system to collapse
c) thought the investment the architects had made in edge conditions was a waste of time
The point here is that sometimes its okay for a system to fail and also its okay to specify what a system won't handle rather than trying to make it handle everything.
Now some architects may leap forward and say "well what about the future, what about extension"
But you know what? If the business doesn't want to pay for these edge conditions then why on earth are you bothering? Sure you should force the point and say "the system won't handle X,Y,Z or pigs learning to type in ancient greek, is that okay" rather than "The system doesn't handle X,Y,Z or greek typing pigs so what we should do is redesign the keyboards to enable pigs to work with the system when they learn to type".
The sort of architectural "perfectionism" that underpins this mentality is, IMO, one of the worst traits of architecture, namely the avoidance of getting into the solution. By putting these edge cases in the way the architecture and design phase takes longer and the dirty solutioning piece when the architecture actually has to be proven can be postponed.
Edge conditions can be non-functional as well "What if your carbon blade procurement system is turned into a Facebook app and gets 10m hits in an hour?" The answer is of course "That won't happen, and even if it did we sell carbon blades to the airline industry so why on earth would we worry about a Facebook app?". Still architects will argue about the "most scalable" way to build the solution that is currently targeted at 5 end-customers with up to 20 concurrent users max.
Sometimes architects claim this is them being "professional" and considering the "future" while taking a "holistic" view. What rubbish, its about architects focusing on architecture and losing track of the big, and simple, picture and merrily pursuing their own mental exercises to demonstrate their architectural prowess.
Edge conditions can be hard to deal with, but that doesn't mean you HAVE to deal with them. Often, in fact most times, the right approach is to declare them out of scope and make it clear what the system won't do as much as what it will.
Technorati Tags: SOA, Service Architecture
2 comments:
If I understand you correctly this is really all about being business-driven, right?
Yup, I'm on the same page with you on this. Architecture astronauts go home!
Of course there's always nuances. Sometimes there is a genuine need that the architect might spot that hasn't been spotted or articulated by a business customer. The trick of course is to have CONVERSATIONS and engage with the business constantly, rather than perpetuating elitist silos. Then, whatever nuances are in play, you should get to the bottom of things.
I absolutely agree with you about "focusing on architecture and losing track of the big, and simple, picture". And as Neil says, "being business-driven".
But if "architecture" (as commonly practised) doesn't give you the big and simple business-driven picture, and focuses attention on the wrong things, then surely we need a different kind of "architecture".
Conversations and engagement are great, and these need to be put together into a coherent and business-meaningful whole. But I don't think line-and-box diagrams quite do the business.
Post a Comment