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 the latest library or framework whereas infrastructure architects are at the other end of the table yakking about the new virtual compute host system. Which group does the Enterprise Architect sit with? Nobody wants to talk about domain models over beer. Well. Some do but those people have no friends.
The question of questions
There have been various blog posts and forum fights over EA subjects for ever. I recently saw a thread that asked a rhetorical question about who was running BPM initiatives at your company. I say ‘rhetorical question’ because it seemed entirely a sales pitch disguised as a legit topic. The discussion thread argued over who should own BPM, the business vs IT. Of course, the vendor may have planted this gem to set 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 the fence is not nearly as big as most people think.
We’re all the Business
The reality is that whether you are in IT or marketing or any other area, 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 node.js 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? Of course there is no answer. Humans 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.
