Earlier today, The Open Group formally announced its new professional association for enterprise architects. I had the opportunity to speak with Allen Brown, The Open Group's CEO, last week about the association (AOGEA), enterprise architects as city planners, business architecture, and membership qualifications. Sadly, I don't qualify for full membership, because I'm not TOGAF or ITAC certified, but there are other levels (associate and affiliate) for enterprise architects (and enterprise architect types) interested in joining.
Allen Brown shared that the primary drivers in escalating the role of the EA:
- "The breaking down of barriers within and between enterprises demands a city planner perspective of the enterprise architecture
- Enterprises need assurance that the staff or service providers they hire have the skills and experience necessary to address the complexities of enterprise architecture
- Professional enterprise architects need a recognized, portable and professional grade qualification"
Since Gian Trotta has a post and podcast on the AOGEA, I'm just going to skip ahead into 'enterprise architects as city planners'. I hope to have information on The Open Group's Business Architecture working group in a couple of weeks.
In our conversation on enterprise architects as city planners, I shared that whenever my father asked me what I did (as a chief architect) I said, "think of it like city planning for business applications". That would resonate. And move my father along to how his Yankees beat my Red Sox, or vice versa. I'm sure other enterprise architects have had similar conversations.
I also shared with Allen Brown that I just read a fabulous, unpublished, paper by Annie Shum of BEA on "Connecting the Dots". Annie's paper covers a range of topics -- meta-principles, fractals, complexity containment, services, SOA, networks of networks, grids of grids -- along with one of her favorite metaphors: SOA and city planning. Annie has graciously given me permission to excerpt (liberally) from her paper. What follows are some of Annie's thoughts on SOA, enterprise architects and city planning. Enjoy!
"...Perhaps one of the most instructive metaphors for SOA is the process of city planning. As I wrote in my SOA & City Planning paper, 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, to the areas of the city/community where they are constructed, and to access to common infrastructure services such as electricity, water, and sewage. In other words, 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. Filtered through a meta-framework prism, the similarity between city planning and SOA is remarkable. Whereas city planning is the meta-architectural framework for building communities, SOA is the meta-architectural framework for collaborative computing.
City planning is a separate profession, distinct from the activities of architect, carpenter, or electrician. In the software development community, carpenters and electricians might correspond to software developers, and architects might correspond to analysts who write specifications for applications. The initial hurdle with this metaphor is that, in most cases, the existing software development community has no de facto analog to the city planner. SOA is destined to resolve this problem by driving into the mainstream a (relatively) new category of IT/business professional, the enterprise architect, whose range of responsibilities is similar to that of a city planner.
Like a city planner, the enterprise architect must have a “big picture” vision that transcends individual units (buildings, services) and focuses instead on the way collections of units (neighborhoods, communities) can fulfill a variety of different purposes. A manufacturing community might consist of a cluster of factories surrounded by homes for workers and connected by railroad links to suppliers of raw materials and component sub-assemblies, as well as to merchants who sell the manufactured products. The community has a need for schools, recreational facilities, police and fire stations, food markets, and so on. Each of these individual facilities could also be used for other purposes. For example, the worker housing could also be used by individuals who do not work at the manufacturing facility, the rail lines could be used to ship goods used for non-manufacturing purposes, and so on. The city planner needs to think about the full constellation of sharable resources that need to be assembled and coordinated.
These observations about city planning illustrate some highly relevant design principles that tomorrow’s enterprise architects should heed when designing specifications for SOA-based IT services. Simply put, enterprise architects must shift their mind-set from today’s stovepipe approach to a connected, virtualized, and federated ecosystem. Unlike the traditional software application architects, the enterprise 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.
One fundamentally important point for enterprise architects is that specifications should be flexible enough to allow for creativity, variability, and initiative in the design and implementation of individual units—whether these units are “bricks and mortar” buildings or individual IT services. However, this heterogeneity must be uniformly constrained by explicit boundaries and formal core tenets for each service in order to achieve the holistic cohesion that enables borderless collaboration and leverages IT asset reuse and the sharing of common infrastructure services.
...
Another important lesson from the city planning metaphor is the co-existence of the old and the new.
...
Managing growth by clustering neighborhoods into communities, communities into cities, and cities into regions is another lesson of city (and regional) planning that has far-reaching applications for enterprise architects designing scalable SOA ecosystems. The fractal-like nature of services allows them to be composed into composite services, which can then be composed into higher-level composite services, and so on. This hierarchy of composite services operates like a nested set of worlds within worlds and makes it possible for each service to retain local autonomy over its own internal operations while also containing complexity and maximizing global interoperability and connectivity through standards-based shared common interfaces. Emerging concepts such as “networks of networks” and “Grids of Grids” exemplify these principles and give new meaning to the old political maxim of “Think globally but act locally.”"
[Note: This post originally appeared on my Business Driven Architect blog on Jan 29, 2007, brought over to elemental links on June 7, 2008]
Comments