GR: What originally attracted you to the Business Architecture discipline, and what does Business Architecture mean for you?
SL: Well Gregg, to me gravitating towards Business Architecture has really been a natural evolution. My career started with an education in computer science, followed by a few years of software development, and from there I quickly realized that analyzing and distilling the customers requirements was a lot more interesting than coding the spec. And then, moreover, understanding the why behind the requirements, and that the needs that drove the requirements was even more interesting. Being able to correlate those needs with the customers business mission, business processes, supporting system, and data architecture while having that bird’s eye view of the whole texture of the organization was extremely compelling.
My professional formation followed my interests. From software development I moved into requirements analysis, system analysis, system engineering, and from there into enterprise architecture, and then into Business Architecture.
Now, in parallel, my management responsibilities have also grown where these days, my primary focus is really on outcomes, on the delivery of services and solutions, on people, on customers, on financials. Now, these elements, people, products, budgets, and customers, they’re also part of an organization’s Business Architecture. When you look at it from this point of view, I really use Business Architecture techniques almost every day, and most people in my role do without knowing that they are Business Architecture techniques.
For example, to understand my customers, I need to learn their business, I need to understand their vision, their strategy, their value chain, and their business processes so that I can then locate the gaps or the areas of weakness in their business and in their architecture. Find where do the problems lie. Do they lie at the boundary between processes? Are they related to the movement of data through the enterprise? Or in the lack of automation? Or, maybe, it’s the human factor, maybe there’s lack of expertise, or lack of obsolete skill sets, or suboptimal organizational structures.
That’s my focus these days and even though I don’t do consulting and Business Architecture directly anymore, I actually use quite a number of techniques that are rooted in Business Architecture.
GR: That’s fantastic. I think when it comes to skills development in this area, I know a lot of what you picked up along the way was on the job training and learning about Business Architecture on the fly.
As you know, The Institute has had an established curriculum in that area for quite some time and for folks that are interested in getting up to speed in Business Architecture quickly, they can take a look at that on the website. We have individual courses and certificate programs, as well as a Business Architecture certification. The Institute is doing what we can to help both individuals and organizations looking to adopt Business Architecture.
Editor’s Note: This is a five-part article and video series.
Watch the entire Top 5 Things to Know About Business Architecture video series
Read the other articles in the series here:
Article 2: Do Organizations Understand the Value of Business Architecture?
Article 3: What will Raise the Profile of the Business Architecture Discipline?
Article 4: When does Business Architecture Make a Difference?
Article 5: What does the Future Hold for Business Architecture?
