A Day in the Life of a Business Architect

Comments: 2
Rate this:
Total votes: 0

Tuesday was a good day at the office, although nothing out of the typical. I attended two high profile meetings with the product management team and a joint product management and technology requirements definition meeting, received news of my promotion, presented a tool that our team built to solve a resource manager’s allocation problem, and got to work on a really cool proposal to map out a business process end-to-end on a single page of paper.

I always thought simplistically that my role as a business architect is to help bridge the gap between what the owners of the company want and what the rest of the organization delivers. I stand in between those who hold the purse and those who wield the hammer (or whatever your tool of choice may be) so I can better link the two to generate outstanding business results. I’m after business outcomes and so should everyone else in the organization, right? It’s that simple.

How then does this translate to what I typically do in the office? Let me talk about last Tuesday and my meetings with product managers and technology experts.

Product managers are a unique lot. I look at them as some sort of alter egos of the owners of the company (or benefactors if you work for a non-profit). These product managers are oftentimes on the lookout for ways to make money or save money. They talk about NPV, ROI, NPS, and they’re deeply passionate about what customers say about our products.

The meeting I attended with the product management team last Tuesday had the same goals. They wanted us to brainstorm on how best to solve our customers’ pain points with regards to setting their preferences across all channels of the organization. The most obvious benefit was to “wow” the customer with all the bells and whistles that technology can buy. But you can’t easily quantify a fungible benefit such as a delighted customer since many factors contribute to that result. You can’t correlate a jump in sales today just because you implemented a project a few months ago whose aim was to delight the customer. It’s more complicated than that and numerous factors can contribute to the same result such as the weather, political upheavals in and around the world, what the other banks are doing, and even the price of corn.

This was where I stepped in. I proposed to the meeting organizer that another way of justifying this project was to look at ways we can rationalize the resource requirements of projects already in the development stage with those in the conceptualization stage thereby saving costs. I was thinking of using our business capability model as a starting point to identify projects that impact this particular business capability. It helped that almost everyone in the room was already familiar with the model and the terms used to describe the problem at hand.

Technology subject matter experts (SMEs) are also a unique lot.

Last Tuesday, I came late to a meeting of senior system architects. When I arrived, someone was already talking about QR codes, iBeacon, and OCR technologies. He was describing the steps for authenticating a customer using any of these technologies and how our servers and software applications can make that magic happen. But there was a problem. What he described was too troublesome and inconvenient for the customer. There has to be better way of solving this problem, I thought.

And this was where I put on my business architecture hat. I described the customer experience as a set of stories or use cases. The benefit we needed to deliver was customer convenience and not something that gets in our customer’s way of completing their task. I walked the team through a business process flow and where we can streamline a step or two. Long story short, we ended up throwing away the fancy sounding solutions to something that was more practical.

At the end of the day, my mind was exhausted. I can’t complain since this was nothing close to the exhaustion I felt after completing a 100 mile ultra run a week before. Each experience gave me reason to celebrate, first as a business architect and second as an ultra runner. I felt good that I was that bridge between the product and technology teams. That sense of accomplishment stayed with me long after I sat down on the train on my way home. And did I mention I also received news of my promotion?

Comments

Drew Guitarte
,
posted 9 years 30 weeks ago

Thanks Ramsay for your

Thanks Ramsay for your encouragement! I'd also love to hear more from others about their success stories. While we can't exactly quantify (at least not yet) our unique contribution to the organization, we can clearly feel the qualitative and soft benefits based on the positive feedback we get everyday from those who see business architects as a "value-add" to the organization. Feel free to post here the link to your site so I and other readers can access it.
Ankit Tara
,
posted 9 years 30 weeks ago

In one short story Andrew has

In one short story Andrew has encapsulated what the spirit and role of a business architect is. It is all about business solutions and being the strategic reasoning to align business and technology. Your story is a good story about how to find better thinking ways to leverage value for the owners when all to often when this is not done people throw technology at the problem. I am keeping a short list on my website of Enterprise Architecture success and failure stoires. Clearly I wish to share your positive experience with my readers under "What does success look like?" Your day in the life of Business Architect is success. Thank you
Ramsay Millar

Join the Discussion

Remind me later

If you wish to make a purchase today and experience an error with the shopping cart, you can place your order over the phone. Please contact us at (508) 475 0475 x15 or toll-free within the U.S. at (855) 300-2686 x15.