I am not an enterprise architect. I’m a business architect. The difference lies in the customers we primarily serve. Historically, the business architecture perspective has been part of every enterprise architecture framework. Only recently has there been a clamor to treat business architecture as a separate profession and discipline with its own set of culture, adherents, and customers.
Enterprise architecture (or EA) has been around much longer than business architecture (or BA) but not much longer than say, project management or business analysis or systems engineering and similar professions. Compared to EA, the nascent BA profession still has a lot to prove in terms of its value proposition. This was the same scenario decades ago when EA entered the scene. But to see systems engineering, project management, and business analysis gain much acceptance as true professions similar to medicine and accounting gives us much hope that EA and eventually BA will become household terms.
I enlisted as a business architect not from a developer or systems analyst background but from an operations and business analysis background. In a sense, I was almost a stranger to EA when I joined BA.
I had a vague idea, rightly or wrongly that EA was mostly about solving information technology (or IT)-related problems. But when I joined BA, I knew that the problems I was going to help solve were those that kept both IT and IT-enabled business managers such as product managers “awake at night.” These decision-makers needed to make judgment calls daily that entail tradeoffs between risk and opportunity. Their ultimate goal, of course is to be successful, however they define success for themselves and for the organization they work for.
Some of my customers’ (or internal clients’) dilemmas involved IT but most were about the following, namely defining business needs, building business cases, eliciting requirements, identifying risks, operationalizing ideas, analyzing stakeholder concerns, pinpointing bottlenecks, tracking customer behavior, watching market trends, organizing projects into programs, illustrating roadmaps, handling conflict, building communities of practice, mentoring, and so on. You get the drift. I signed up for BA because I’m a problem solver, of all types of problems that decision-makers face every day. I enjoyed the thrill of delighting my customer and seeing them succeed because of my contributions. I also appreciated the fact that they kept coming back for more.
In a nutshell, I’m a business architect and not an enterprise architect because I help decision-makers succeed, and these decision-makers may not be the primary customers of EA. Isn’t it about time that these decision-makers get the help they need?
Postscript:
I remember the time not too long ago when I joined the BA team in Community Banking. I asked the manager who hired me why he thinks I’m fit for the business architect role. He said that I have a “strategic” point of view compared to other business analysts or system architects he knew. Then I remembered that I attended a meeting with him and a product manager. We discussed the business requirements for a particular project. I strongly proposed a more high level cross channel and inter-organizational point of view of business requirements elicitation which struck the product manager as novel. Perhaps that experience, simply was the start of my business architecture journey.
There are no products in your shopping cart.
| 0 Items |
Membership at BAInstitute.org includes access to our other communities.
