It has been a few weeks since the Gartner Enterprise Architecture Summit conference in Grapevine, Texas. It continues to be my favorite conference, probably because it seems to be the only US-based conference dedicated entirely to the EA discipline. For me, attending this conference has three benefits. One, it allows me to validate initiatives and approaches, that I as an architect push within my organization. Two, it allows me to have numerous conversations with my peers about the state of their EA practice. This is, of course, invaluable because it puts the “reality” lens in front of what Gartner says. Three, it exposes me to information about developing trends in EA.
At the last conference, one of the recurring themes appeared to be “Vanguard EA” and how it plays in the era of digital business. The key premise here is that the Vanguard EA is the part of EA discipline that is about looking into the future, about innovation, and about steering the enterprise in close partnership with Business. This is in contrast with the Foundational EA, which is more about traditional, perhaps more reactive and IT-focused practice. In other words, Foundational EA is what most EA organizations are today, while Vanguard EA is this emerging trend which represents the place where most EA organizations would like to be. From what I could gather, Gartner believes that there will always be room for both Foundational and Vanguard EA, but in order to thrive in the digital business era organizations must evolve their EA practices beyond their foundational character.
This is great and I couldn’t agree more. Here is the disconnect though… Virtually in all hallway conversations I had at the conference, attendees confirmed that the idea of Vanguard EA is a very elusive dream, as most EA organizations still struggle to be invited to the “business” table. It is true even for what Gartner would consider foundational EA work. In one of the sessions, Gartner speaker suggested that we as Enterprise Architects should invite ourselves to the business table, by demonstrating the value that we bring to business discussion. This is nice, but also strikes me as a little whiny. It’s like a kid saying that if another kid doesn’t want to play with him then he would just keep bringing him candy in hopes that one day he invites him to play. This is a precarious position to be in… and it brings me to the point of this post. It seems that Gartner may be preaching to the choir. Don’t tell us, architects that Vanguard EA is a way of the future, tell the business!
I don’t have the official statistics but I am willing to bet that the vast majority of attendees were architects or managers of architecture organizations. Very few attendees were true business leaders. In one of the closing sessions, the audience was asked “how can we make this conference better”. One of the attendees responded, “offer a two-for-one deal, where you get your conference pass for free if you bring a business person with you!”. I’m not sure if this particular idea is feasible but it clearly shows that many of the attendees share my sentiment. So how about it Gartner? Perhaps it is time to stop preaching to the choir and direct your message to business leaders instead.
I will be speaking about the practical approach to integrating enterprise architecture at the SATURN 2014 conference in Portland, OR. Abstract below.
Integrating Enterprise Architecture
In the era when contributing to business value is the principal consideration of IT, large and distributed organizations face a challenge of understanding how their capabilities are realized and how they can synchronously evolve them in alignment with business strategy. Structured information coupled with efficient architecture processes sets the foundation by addressing several issues:
- Complex interdependent systems that evolved independently increase technical debt.
- Nonexistent, inconsistent, or scattered architecture descriptions make planning difficult and extend the delivery time of solutions.
- Unclear dependencies of business capabilities on technology lead to weak commitment to business goals.
The TOGAF, ArchiMate, and Sparx EA tools are cornerstones of Progressive’s approach to integrated enterprise architecture. By leveraging existing systems-development life-cycle processes and architecture-governance structures, Progressive implemented elements of the TOGAF Architecture Development Method and established consistency in defining and reviewing target architectures. Investing in modeling skills and introducing standard building blocks for architecture models allow architects to describe the systems and capabilities in a uniform way that produces an overall view of the current and future states of the enterprise. This presentation presents a practical approach to implementing integrated enterprise architecture at a large organization. Specific tools, frameworks, and languages serve only as a context for this experience-based story.
Recently, I attended the Building Business Capability (BBC) conference in Las Vegas. I was tempted mainly by the Business Architecture track as I was curious to learn more about the current state of affairs in that field. Here are some of my observations, and conclusions after attending the event.
- Confusion about Enterprise Architecture and its scope is further magnified by more confusion around Business Architecture. Various speakers made different pronouncements about the relationship between the two. Most saw Business Architecture as a component of Enterprise Architecture but some attempted to present Enterprise Architecture as being about IT and Business Architecture being about business. Another speaker suggested that Business Architecture overlaps with Enterprise Architecture but still is a distinct discipline that must “interface” with the Enterprise Architecture.
I agree with the majority that sees Business Architecture as a component of Enterprise Architecture. As to other views, well…, I find it fascinating that some people need to complicate things. Of course, Enterprise Architecture is about the enterprise, and the enterprise is about business, DUH! Need we say more? Presenting Business Architecture as something separate from Enterprise Architecture only increases confusion and…just wait, will lead to more frameworks. God knows we don’t need any more architecture frameworks. If you insist, then let’s fix the ones we have by giving them more business focus (…looking at you TOGAF…) instead of inventing new ones. In any case, enough with inventing more distinct “architectures”.
- Traditional roles of Business Analysts and Architects are evolving. Both roles are pushed to pay more attention to business value and business differentiation. Currently, in most organizations Business Analysts are relegated to requirement gatherers for IT projects. Their main focus is to translate requirements received from business into specific definition of IT deliverables and to perform validation of those requirements upon completion of implementation. There is very little going on there in regard to actual business analysis, not to mention Business Architecture. As Business Architecture rises to more prominence, Business Analysts must assume a role of true analysts and partner with Enterprise Architects in a comprehensive approach to Enterprise Architecture. At the same time Enterprise Architects are pushed to reach out to business and expand their role in the Business Architecture realm to make Enterprise Architecture more business-centric and thus more relevant to generating business value. This will likely lead to interesting dynamic with career paths. Both Business Analysts and Enterprise Architects are told that being Business Architects is in their future. However, Enterprise Architects also consider themselves well versed in technology, while Business Analysts not necessarily so. So where does this leave us? Will Enterprise Architects become generalists who rely on Business Architects, specialists, for the Business Architecture part of Enterprise Architecture? Or perhaps Enterprise Architecture will be pushed back to being again only about IT and Business Architects from Business Analyst ranks will direct Enterprise Architects how to shape the IT side of the enterprise?
- Business Capabilities emerge as the way to provide a common taxonomy that can bridge the gap between business and technology. Capabilities allow architects to focus on “what” rather than “how”. They provide an anchor to relate systems and their underlying technologies to the business context, which includes organization, people and processes. Furthermore, they help break the silos, ever prevalent in larger organizations, which often represent the obstacle to effective Enterprise Architecture.
Some can argue that capabilities and capability models have been around for a while and there is nothing new here. For me, the new thing was the evidence that companies start registering real successes with capability approach to Enterprise Architecture. It seems that capability models are finally taking off, coincidentally at the time when Enterprise Architecture, after some soul-searching, is beginning to focus on business value.
Overall, BBC was an interesting conference. Not great, just good. I found that too many speakers were contradicting each other, but truth be told they were simply expressing their own opinions and there is nothing wrong with that. I suspect that the conference was of most value to Business Analysts especially with several BA-oriented tracks. Business Architecture track was messy but it is probably due to the fact that most of us still try to wrap our minds around how it fits with everything else. 🙂 I will consider attending next year, if only to watch the further evolution of the Business Architecture concepts.