elemental links

Enterprise Architects, Professional Escalation, and City Planning

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]

Thinking Out Loud: SOA Maturity

I'm working on a for public consumption project that I call "service-orienteering".  I'm borrowing a trail system metaphor to show the numerous trails and stops to reach a final destination of SOA-based business value.  Because let's face it, while achieving a mature SOA is a journey, delivering business value is the ultimate destination. 

That said.  I got to thinking about SOA maturity and SOA maturity models.  The current SOA maturity models focus on technology adoption, scope of integration, and service interaction.  While (as friends politely pointed out to me) there is nothing wrong with these models, they tend to have a narrow focus -- the technology of SOA.

Because I tend to see things through  business-driven goggles, I'm thinking the maturity of an SOA should be measured by:

-      adherence to the architectural tenets (loose coupling, cohesion, sharing, and perhaps semantic interoperability)

-      the organization’s capability to share (people, process, tools)

-      the breadth and depth of the service catalog as compared to the business architecture – services might be in house, from partners, or SaaS

-      the business criticality of the SOA solutions

-      the business complexity of the SOA solutions

I'm curious, what do readers think?  Shouldn’t we measure SOA maturity in terms of the capability to deliver business value?  Am I in left field? 

If you're intrigued to see how this "service-orienteering" project is shaping up, I'll be giving an "alpha version" talk at SHARE in Tampa in February.

My (first-ever) Luddite Moment

Often, when I speak with other technologists, particularly women, they comment on how unusual, yet refreshing, it is to speak with a (another) woman who is passionate about technology.  Truth be told, it’s not so much that I’m passionate about technology, but rather the possibilities technology creates -- for business innovation, societal advancement, easier living, and/or entertainment. 

Today though, as I was perusing the (online) Wall Street Journal, I read two articles that stirred the (soundly) sleeping Luddite in me.  The first article (subscription required) describes Walmart’s new workforce scheduling system that uses historical (prior year), recent (7 weeks), and real-time (15-minute) customer traffic data to determine optimum employee scheduling.  The optimization is for customer experience and profitability. 

So, periods of high customer traffic and sales will have more staff than low periods.  This makes perfect business sense.  Customers don’t have to suffer through long lines during busy periods.  Walmart doesn’t have to pay surplus staff to hang around during slow periods.  I get this.  Forecasting (sales, inventory, workforce) is a critical, longtime, retail practice:

   

In the past, store managers for Wal-Mart and other huge retailers, including Sears Holdings Corp.'s Kmart, Payless and J. Crew, scheduled workers based on store promotions and weekly sales figures from the previous year. By comparison, the software systems created by workforce-management software companies such as Workbrain Inc., Kronos and CyberShift Inc. rely on real-time data feeds, such as sales rung up at the cash register and customer traffic.

What stirred my sleeping Luddite was the impact the real-time element has on employees:

   

But while the new systems are expected to benefit both retailers and customers, some experts say they can saddle workers with unpredictable schedules. In some cases, they may be asked to be "on call" to meet customer surges, or sent home because of a lull, resulting in less pay. The new systems also alert managers when a worker is approaching full-time status or overtime, which would require higher wages and benefits, so they can scale back that person's schedule.

   

That means workers may not know when or if they will need a babysitter or whether they will work enough hours to pay that month's bills. Rather than work three eight-hour days, someone might now be plugged into six four-hour days, mornings one week and evenings the next.

   

Some analysts say the new systems will result in more irregular part-time work. "The whole point is workers were a fixed cost, now they're a variable cost. Is it good for workers? Probably not," says Kenneth Dalto, a management consultant in Farmington Hills, Mich.

(emphasis is mine)

Seems like a lot to ask of people averaging $10/hour. 

The second article (subscription required), written by John Miller of the National Review, questions the use of book circulation software in libraries as the sole criteria to determine if a book deserves shelf space. 

   

"For Whom the Bell Tolls" may be one of Ernest Hemingway's best-known books, but it isn't exactly flying off the shelves in northern Virginia these days. Precisely nobody has checked out a copy from the Fairfax County Public Library system in the past two years, according to a front-page story in yesterday's Washington Post.

   

And now the bell may toll for Hemingway. A software program developed by SirsiDynix, an Alabama-based library-technology company, informs librarians of which books are circulating and which ones aren't. If titles remain untouched for two years, they may be discarded -- permanently. "We're being very ruthless," boasts library director Sam Clay.

   

As it happens, the ruthlessness may not ultimately extend to Hemingway's classic. "For Whom the Bell Tolls" could win a special reprieve, and, in the future, copies might remain available at certain branches. Yet lots of other volumes may not fare as well. Books by Charlotte Brontë, William Faulkner, Thomas Hardy, Marcel Proust and Alexander Solzhenitsyn have recently been pulled.

   

Library officials explain, not unreasonably, that their shelf space is limited and that they want to satisfy the demands of the public.

Miller goes on to question what libraries are for:

   

What are libraries for? Are they cultural storehouses that contain the best that has been thought and said? Or are they more like actual stores, responding to whatever fickle taste or Mitch Albom tearjerker is all the rage at this very moment?

Noting the broad availability of low-cost books, Miller urges libraries and librarians to embrace their differentiation, rather than compete as lowest cost providers of mass-market titles:

   

Instead of embracing this doomed model, libraries might seek to differentiate themselves among the many options readers now have, using a good dictionary as the model. Such a dictionary doesn't merely describe the words of a language -- it provides proper spelling, pronunciation and usage. New words come in and old ones go out, but a reliable lexicon becomes a foundation of linguistic stability and coherence. Likewise, libraries should seek to shore up the culture against the eroding force of trends.

   

The particulars of this task will fall upon the shoulders of individual librarians, who should welcome the opportunity to discriminate between the good and the bad, the timeless and the ephemeral, as librarians traditionally have done. They ought to regard themselves as not just experts in the arcane ways of the Dewey Decimal System, but as teachers, advisers and guardians of an intellectual inheritance.

The thought of libraries dumping classics is just plain disturbing to me.

Now, the above in no way translate to “technology is bad”, rather, people sometimes make bad decisions about the use of technology.  So, along with an appreciation of a technology’s possibilities, we need to always recognize the human consequences.  May all our inner-Luddites sleep well…