August 2007

Monthly Archive

Inferior Tracks Lead to Superior Locomotives

Posted by on 05 Aug 2007 | Tagged as: Agile, Architecture, DotNet, Java, Leadership, Scrum, TDD, XP

Larry L. Peterson, professor and Chair of Computer Science, Princeton University, gave a great talk on PlanetLab: Evolution vs. Intelligent Design which I believe is interesting to people involved in emerging architecture. One of the Agile Manifesto for Software Development’s principles is:

The best architectures, requirements, and designs emerge from self-organizing teams.

Remember this principle while listening to the talk.  Larry points out many examples of when this is true and the issues that can occur as a result.  These issues are all resolvable but the resolution may not be what you initially expect.

One of the great discussion points, in my opinion, was on how inferior tracks lead to superior locomotives.  The story is that track standards across the American west were much more liberal than previously defined on the east coast and Europe. Therefore, European trains could not run well on American tracks and the locomotive industry in America had to cope with this issue. The American locomotive industry then created much more robust locomotives which dealt with the real world issues running trains on these tracks.  Coming from the Jini community of y’ore this reminds me of the 8 Fallacies of Distributed Computing and how much abstraction can be designed before increasing missing detail overhead in software development.

Value-Driven User Stories Exercise Paper

Posted by on 05 Aug 2007 | Tagged as: Agile, Product Owner, Scrum, XP

In a past blog entry I had discussed an exercise for generating user stories based on value statements.  I have written a paper since then that describes in more detail how the exercise works.  If you are interest please download the paper.  If you try it out let me know how well it works for you.

Comparing the Product Owner and Enterprise Architect Roles

Posted by on 04 Aug 2007 | Tagged as: Agile, Architecture, Leadership, Product Owner

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.

Perspective Based Architecture

Posted by on 04 Aug 2007 | Tagged as: Agile, Architecture, Leadership

I happened to run into Lewis Curtis on a plane recently and we started a discussion on Perspective Based Architecture that he had been working on for a few years.  Here is the mission statement from the main web site:

“At the end of the day, no matter what technologies, vendors or methodologies are utilized, all IT architects must address very difficult questions for a successful solution.  Fifty years ago, today and fifty years from now,  IT architects will still need to address these difficult questions.  Therefore, The PBA Method focuses on capturing those questions from architects in a community model organized within a meta-model in an easy to use capability complimenting most methodologies and processes to promote more successful architectures.”

I thought this was a nifty way to communicate the questions we must answer in business which is supported by technology and software applications.   I believe that many of the topic areas in the meta-model are useful not only to IT Architects as proposed but also to entire IT and software product delivery organizations.  Take a look and I will post more ideas on this subject in the near future.  I will be at Agile 2007 hosting a discovery session on “Architecture in an Agile Organization”.  Please join me if you are heading to the conference.  I am interested in meeting many new people in the technology and software development community.