I was an enterprise architect before I knew what the term meant.
I just didn’t fit in with all the other late 90’s start up hotshots. I wasn’t a developer (unless you include html and flash, which I don’t). I wasn’t a network techie. I wasn’t a DBA. I wasn’t a business analyst. I definitely wasn’t in sales or marketing. Frankly in the world of a 5 man internet start-up, there isn’t much room for anyone else. I was just the guy who was always trying to figure out how our technology matched up with the stated need. In short, I spent my start-up years wondering why anyone needed the things we were coming up with.
“What problem is this solving?”
A room full of 20 year olds hyped up on Dew and coffee with angel investor dollar signs in their eyes weren’t interested in hearing that question. In the second half of the 1990s, it didn’t really seem to matter what you were producing so long as the hype was sufficient to garner buyout attention. And trust me, that worked (for a while). I thought I was going to retire forever.
“What business value does this technology provide?”
Another question met with bewildered stares. When frenzied, iterative development and flowing, constant delivery of features is the drumbeat, the need to assess the solution within the context of the business is not high on the priority list. Well, if you lived through the dot-com bubble in the 90s, you know how that worked out.
You don’t have to fit the mold.
I entered corporate America and was thrust into a role where I had to be scrappy. I managed firewalls, LDAP servers, web servers and application servers. I was part of a team of folks who had an instinct for how systems had to be assembled into solutions in order to address “requirements” conjured by the development teams. I say requirements in quotes because the reality is there was very little in the way of formal methodology. It was more along the lines of “hey I need to be able to hit MQ server number five” and so we made it happen. The difference here was that when we made it happen, we did it in a coherent, planned, methodical way and we developed a sense of strategic direction with our planning. We aligned our technical machinations with perceived and anticipated changes in the business. Keep in mind we rarely ever talked to the business, let alone knew who they were.
So we began calling ourselves architects.
In the structured, nurturing, cash-rich environment of Fortune 100, it is easier to talk in the terms familiar to architecture. Terms like governance, requirements, capabilities, domains, logical, conceptual and… oversight, all have much more meaning and real-world impact in such an environment. There are boards of review and approval committees and various needs of various fiefdoms for input and credit. If architecture and strategy didn’t exist, they would have to be created in order to make sense of Fortune 100 IT. The problem, of course, is the stifling and oppressive nature of such organizations. They didn’t, at this time, provide much room for the innovator to work his magic. What is IT architecture if the conditions stifle innovation?
It wasn’t until later, when I was a consultant, that I realized we had been doing proto-EA work during this time. It wasn’t possible for us to truly conduct an EA program at that time in that company, nor would we have known how if we had even recognized the need. The silos were in full effect and there was simply no way to engage the business without pissing a bunch of people off higher up the chain. So we muddled along doing the best we could in a mostly reactionary manner.
There was no champion.
Consulting provides a window into the world of companies. If architecture was a college course, consulting would have to be a required internship. We learn by doing and there is no better way to do than to do at many companies in many industries, succeeding at some and failing at others. Each company is different but has similar qualities and patterns begin to emerge if you consult for enough time. It was not as a technical consultant but as a management consultant that I learned one critical key to EA that I had never fully appreciated: the champion. I discovered a pattern in EA programs across many different companies. It isn’t rocket science: Without someone in a position of power and/or holding the purse strings behind you, any EA program runs the risk of being relegated to the role of a lofty thought experiment. This was my experience in industry.
It’s just as important to learn what doesn’t work.
One of the ironies I always think about is how I started as a technologist and ended up being almost an anti-technologist. Technologists are hard-wired to see every problem as one that can be solved with a tool. It is instinctual. The reality of course is that most problems I have ever encountered were hardly ever a problem with technology. Most problems end up being a people problem. Yes tools are a Godsend for solving problems, for automating things and making solutions easier to implement and manage. Tools enable success, in many cases. But the problem was rarely in the logical or physical views, the domain models or conceptual models; the reference architecture itself was hardly ever really fought over. In fact, as highly paid technology and management consultants, we often joked that we knew the future state as soon as we heard the business problem. The artifacts themselves wasn’t where the value was. The value was in understanding the complex web of relationships between the people and the things that they do when they work. The value was in instinctively knowing, in your gut, the right direction to go in aligning the technology with that complex web of relationships. Failure was (is) pretty common. It isn’t because the technology is crap, it is because as an architect, an Enterprise Architect, you are dealing with the most complex system of all: people. Knowing human beings is perhaps one of the most critical foundational skills of a good enterprise architect.
The industry might just be wrong.
So why talk about EA? Well far be it from me to suggest I have knowledge that the industry collective does not. I don’t, no one can. But I do want to spend some time relating some of the things I’ve learned about working with enterprise architecture because I don’t think the story is told well enough or often enough. There are notions of this field out there that I think are flat out wrong. There are far too many people running around calling themselves enterprise architects with no clue what it actually means. I think the IT industry itself does a poor job as a whole understanding the needs of its most important customer, the business. Quite honestly, I think the industry might often be wrong.
