Interestingly, my recent post on facilitating the service lifecycle spawned an email conversation on this topic. The gist of the conversation was that many of the tools out there in the SOA space are targeting the Building Inspector, rather than the City Planner or the Developer/Landlord (developer in the city planning sense, not in the software development sense).
Annie’s paper points out that:
City planning is not concerned with the design and construction of individual buildings. Rather, it is concerned with the multi-aspect relationship of individual buildings to one another… city planning is not about building architecture; it’s about meta-architecture for designing communities of buildings by focusing on common infrastructure, governance and cohesion.
This is a great statement, and very useful when trying to explain the role of an enterprise architect. James McGovern recently brought up the need for architects to work downward to the developers. I think the city planning analogy can be a useful tool in helping to create an understanding of the roles involved. Interestingly, recent events in my town demonstrate how well this analogy works, even in providing some guidance to how collaboration should occur. The town I live in is growing. Years ago, it would have been considered a rural farming community. Now, with the normal suburban sprawl, its close proximity to downtown St. Louis is making it more suburban and less rural. The biggest event associated with this growth is about to happen: a major tract of farmland is going to be turned into a major shopping and industrial complex. The opinions page in our local paper has become very active on the subject. The individuals expressing their opinions are akin to the individual developer in the enterprise. The city council is akin to the enterprise architecture team. I would not want to leave this effort in the hands of the individuals who are expressing their opinions. They simply don’t have the right perspective to make these types of decisions. The city council has been working on this for at least 5 years, studying the implications of tax incentives, infrastructure development, impact on local businesses, etc. The roles are clear. What I do believe in, however, is the ability of the individual to participate and contribute to the process, and the responsibility of the city council to solicit input and communicate their direction. After all, this entire process may have begun with an individual land owner selling their acreage to the developer to begin with.
The same holds true for the corporate enterprise architect. While enterprises are not democracies, so your EA can’t be recalled or replaced at the next review cycle by a vote of the developers, the best practices of a democratic style of government should be followed. The Enterprise Architect must be producing documents for upward communication (business and IT executives), lateral communication (other architects), and downward communication (developers, operators, engineers). Likewise, they should be soliciting input from all three directions, as well. Communication should never be one-way, nor should it be one size fits all. Some of the best ideas may come from people in the trenches, and some of those people may be a future architect. I was one of those people in an organization some 7 years ago. Annie’s paper points the importance of communication and collaboration with this statement:
…the entrprise architectsâ€™ role extends well beyond software coding specifications. Instead they must also act as the chief enablers of borderless collaboration by coordinating and prioritizing the input from disparate groups with different needs, interests, and views, including business stakeholders, software architects, developers, and DBAs, as well as external partners, suppliers, providers, customers, auditors, and so on.
Brenda pointed out that this document hasn’t been published yet. Based upon this excerpt, I hope it will be published. Add me to the list of interested parties.