Correctness is normally used to describe the technology side, solution X is more "correct" because it obeys more rules or exhibits better technology pieces. The goal in this mindset is to be as correct as possible, rather than being good enough for he job at hand.
If architecture is to be about delivering what the business wants then there are three things that should be at the front of an architects mind
- Is it good enough
- Can my team deliver it?
- Can we support it?
Convenience over Correctness therefore should mostly focus on convenience as that will help deliver something at a better business price and which more developers (read cheaper developers) will be able to deliver and which more people in support (read cheaper support) will be able to maintain.
Architecturally it is the convenience that represents the best choice even though technologically it is not the correct choice. If I have a team of VB 6 developers and have to build a distributed multi-threaded application then the technologically correct choice might be to architect using REST and Erlang, however the business correct decision would be to architect around the limitations of the team and the platform to enable that team to deliver the solution. Yes it could be argued that hiring 20 Erlang guys with REST experience could have got the job done quicker head-to-head, but not if you factor in hiring time, recruitment costs and the increased salary costs and this was also not the challenge that the architect was presented with.
Architecting from the Ivory tower is easy. Assuming everyone is as smart as you are is easy. The real skill is in understanding the complexities and picking the technologies and approach that is most convenient for the people you have and good enough for the problem being solved.
If architects are to change the perception of IT then we must focus on business objectives over technological correctness. Brunel was right that the "correct" gauge should be wider as the previous one was merely a convenience. That was the engineering and technology view, the business view was that standardisation and the majority was the correct view for economic development.
In delivering business solutions it is the business correctness that matters over the technology correctness this means focusing on the people available for delivery and matching their skills to the architectural proposals and focusing on support to ensure that it will operate effectively.
Architecture should be about making it work in reality, not making it work better on paper.
Technorati Tags: SOA, Service Architecture
8 comments:
Amen. At the end of the day it's about getting stuff done that makes sense for your business. Academic discussions among architects especially around SOA is getting a bit crazy.
Hey Steve!
I was wondering if you could post someting about talking about architecture *itself*.
It seems to me that there is a lot of discussion going on about how architecture is important, but very little discussion on *actual* architectures and the considerations that led to them.
As a young and unexperienced SOA architect (kind of an oxymoron - unexperienced architect), I find it hard to find good literature to learn from.
Thanks :)
Just as it is easy to architect in an ivory tower, It's also easy to pontificate about people over technology while completely ignoring the technological problems. Becauer people are clearly more important to auccess in the big picture, it is a non sequitur that the technology does not matter. By making this leap, you shut down debate by implicitly accusing those favoring correctness as "not designing for reality". This has always been a deplorable debating tactic.
That said, I agree with the other points you have made. You can't always pick the most cost effective, productive, or reliable solution due to complicating factors in people, politics, timing, risk, and organizational culutre.
The problem is that many technological arguments of the sort we engage in on the blogosphere are not necessarily targeted at the goal of directly shifting IT investment patterns. They are targeted at "raising the bar" in industry, shifting its value systems, through the tools, techniques, and mindsets made available by vendors, thought leaders, and (more recently) online communities and projects.
The sort of convenience that Steve was referring to was "convenience for the junior developer", not "convenience for the business". In other words, to my understanding, it was a call against forcing technology choices through the prism of a junior developer's value system in favour of a value system that recognizes the bigger picture. Forcing machine interactions through a development construct like a procedure call implies that the junior developer's mindset should the centre of the universe, not the business' broader concerns. Isn't this why, after all, you have raised SOA out of the technology world, into "business services architecture"? To focus on what's needed to design and maintain business interactions without worrying about how a developer would do it? That to me is a top down approach to improving the industry. Its drawback is that it is hard to divorce an idea from the technology and the tie it back from the technology (without high priced consulting :-). An alternate approach is bottom up, wherein we change the technology to better fit the bigger picture. That's what I felt the Convenience over Correctness was attempting.
IMO, our disagreement keeps coming back to this point: whether it is a worthwhile, or even possible, endeavour to shift technology sensibilities (particularly in tool makers) in a productive direction, or, that such a goal is misguided, and that any succeses will be inevitably perverted and misused to the point that the improvements in question lead to a "one step forward, two steps back" mess.. Given this, we should focus on the business problem primarily and map back to the eternal crapfest of technologies we have to work with.
I tend to be ambivalent about this, though clearly I lean to the "bottom up" approach, despite evidence on both sides.
Stuart,
The past record of technology alone changing IT practice is like the batting average of a one armed blind man facing the Yankees. Equally given that ultimately IT must be about delivering to the business I find it a little sad that IT continues to focus on the weeds as if that will magically make the problem different.
Bottom up has failed, it will continue to fail. The only real changes come when people start changing they way they think about IT and making IT secondary.
I agree that taking the logical approach and trying to drag technology along is a tough journey but surely its better than in 3 years time having another tech X v tech Y discussion in the continuing crapfest of technology led solutions.
Well, again, I'm ambivalent.
One one level, I fundamentally disagree with your position, as long-run technology has driven much more drastic changes in the business than vice versa.
On the other hand, one has to put the business first in order to take advantage of such technology advances; you can't just sign a cheque and be done with it.
But, I'll leave it for now. :-)
I completely agree that in the long run that technologies have made a massive impact on business, but I'd say that this has been when the business took control. Look at the PC, the "IT" folks were going on about mini-computers and how the PC couldn't possibly be a serious computer.
Technologies matter but I 100% agree that it is focusing on what is to be achieved that really matters.
Surely the architectural issue in your example is that the proposed project does not fit the current business strategy - which has driven an investment in VB.
As you point out here: http://service-architecture.blogspot.com/2008/07/soa-success-value-over-technology.html
the key business (architectural) imperative is to standardise to drive out non-differentiating costs. Either the proposed project is differentiating (and therefore would drive a broader change in direction) or it isn't (and the solution needs to be challenged).
IMO, the key issue for such examples is to ensure that the business owns the whole life cost of the project and resultng business process + supporting IS, including the impact on the rest of the business of having such a whacky add-on.
The pain won't be the tech. choice, it will be because the VB developers are out of their area of competence.
I've seen that a large part of the continuing cost of IT delivery comes from having to take ownership of business decisions from earlier budget cycles that have not got focused budget support, but which are 'spread' across the whole IT cost of delivery.
If my context is correct, Convenient costs more than Correct ;-)
I don't think investment in VB could be a business strategy, its more about that is what you have so deal with it.
I completely agree on the business ownership of the cycle, which in turn means IT folks who are more business centric. What I was meaning around the application is that I am expected to know my stuff (TPA) so its my job to work with what I have. To complain bitch and moan about the limitations to be sure but to get it done.
Convenient often does cost more than Correct, but Correct should be a business judgement not a technical one.
Post a Comment