At an IASA meeting approximately 1 year ago, we came up with the following definition for what an Enterprise Architect does:

“What does an architect do?”

  • Understand the client’s world view and grasp their problems
  • Serving as the client advocate, Envision solutions to the client’s problems
  • Serving as the client advocate, Partition the problem up into manageable units or work
  • Serving as the client advocate, Communicate the solution to all stakeholders and participants
  • Serving as the client advocate, Ensure the solutions are delivered as expected

With the exception of the “Partition” entry, these bullets are derived from Marc and Laura Sewell’s definition taken from their book, The Software Architect’s Profession: An Introduction (ISBN 0130607967). I added the “customer advocate” and I believe it was Nick Malik who added the “Partition” element to the list. Many people who are title Enterprise Architect in organizations do not have the above responsibilities. I find that EA tends to stand for information gatekeeper. They own items such as the data model and continually look for ways to increase business intelligence and minimize divergence in solutions to manage throughout the organization. This is why I believe that many development teams and project management groups refer to EA as an “Ivory Tower”.

Since the Enterprise Architect role has become synonymous with the “Ivory Tower” approach I am looking for a new title. In Scrum, there is a role identified as the Product Owner which resembles many of the characteristics listed above. A Product Owner’s responsibilities include understanding the client’s world view and problems, envisioning solutions, partitioning work into manageable units, communicating the solution, and ensuring the solutions are delivered. The difference between an Enterprise Architect as we envisioned above and the Product Owner role was something that was unwritten but understood by the group:

How much of the “how” do we envision in the solution?

The Product Owner role revolves around the “what” not the “how”. This is a simplistic way to describe it but captures the intent nicely in most situations I have worked with Product Owners. It has been my experience that Enterprise Architects can be a supporting person to the Product Owner mostly in the partitioning of work into manageable units. They can also be helpful mentors and coaches for the software development teams introducing existing infrastructure, understanding team capabilities and issues with current tools, describing higher level architecture roadmaps, taking feedback from teams, and managing vendor relationships.

These are just a few ideas on how Product Owners and Enterprise Architects, as described by our group, can work together for the betterment of software delivery. I am interested in hearing other’s thoughts on this subject. Is this a topic of interest to others in the Agile and software development community? If so, I would like to follow this up with more real world examples of how I have seen this work. Thanks.