What do you do for work?
For IT architects it can often be difficult to describe their job to their friends and family. Often difficult? Try impossible without grade-school visual aids. I think this is usually because for those from a technical background, they define their jobs in terms of the technology they work with. Application architects typically spend happy hour talking about Java whereas infrastructure architects are at the other end of the table yakking about the new pSeries model. Which group does the Enterprise Architect sit with? Nobody wants to talk about domain models over beer.
The question of questions
There was a recent blog post over on the Ultimus website that asked a rhetorical question about who was running BPM initiatives at your company. I say rhetorical because I can’t imagine a BPM software vendor considered for a moment that the answer was “IT”. Of course, they may have since this sets up the classic IT vs the Business conflict that I think is increasingly a straw man argument devised to be knocked down by helpful sales people. This isn’t to say that the two sides of the fence don’t have significant differences on how they view the world, but I AM saying that I don’t think the fence is nearly as big as most people think.
We’re all the Business
The reality is that whether you are in IT or marketing, your only real purpose is to support the business of the company (i.e. making money). This manifests itself in different ways naturally, but at the end of the day a well run business measures its employees on how much the contribute to the success of the company, regardless of which department or business segment they’re in. To the extent that architecture activities can be easily defined, therefore, it can be said that an IT architect is a businessman. He’s enabling the success of the business by applying his unique skills to that end. In this respect, the architect is no different in his ultimate job function than, say, the marketing analyst or the sales director.
This is obviously an oversimplification, but the point is still valid and critical for IT folk, especially architects, to get their heads around. Architects are often accused of living in dreamland, conjuring up ideal scenarios and various other mystically complex situations that nobody else really understands. Architects are sometimes cut out of project activities or otherwise avoided for this reason. Architects equal time, money, bureaucracy and needless complexity, so the complaint goes. While I believe this is a stereotype, it is grounded in the notion of architecture for the sake of the architect (or vice versa). You’ve probably seen it before, the meta-model model or framework of frameworks. At some point the activities associated with architecture become detached from the original business purpose and seem to exist only to service themselves. It is usually this self-indulgence that turns project stakeholders off.
Perception of self-interest is a problem
If you’re being measured against the standard of business success, why wouldn’t you want to perform as best you can in support of those metrics? If I’m the application architect, it should be in my self-interest to promote the best solution available to meet the requirements put forth by the business. Why would I actively pursue some other plan that ultimately does nothing to enhance my value to the organization?
The problem here is a simple miscalculation of self-interest. Since we’re talking about humans and not algorithms (mostly, I’m pretty sure all financial analysts are really mere simulacrums), we have to recognize that we each act not in our own self-interest, but in our perceived self-interest. For the poor application architect I keep picking on, he may be calculating his self-interest in terms of how much he can demonstrate his superior knowledge of struts and not whether his elegant design actually enables the required business capabilities. I think we’ve all seen how that usually ends up.
How do we recognize flawed calculations of self-interest and align with the ones that truly matter? That’s my rhetorical question of the day. Of course there is no answer. Humans, those who aren’t financial analysts, will never escape that flaw of ego which fires our passions to do just the wrong thing at just the wrong time. The only real way to mitigate it is to always return to the centrality of any IT activity at every point in your 8 hour workday: how am I helping the business right now? If it takes you too long to answer, you’re probably not doing the right thing.
There is no IT
Recognizing that technology doesn’t exist for the benefit of itself and is merely a means to an end is the biggest first step any technical person can take to climbing over that small fence between the business and IT. Technology within the business is simply another domain of functionality who’s objective has to be enabling the overall success of the company. For all intents and purposes, there is no special entity called IT. There are merely operators of the business with varying roles and expertise. To answer the classic “who’s driving BPM initiatives” question, the answer is simple: we are all the business.