Wednesday May 18, 2011

Combining SOA and WCM

A good friend of mine was in town this week to visit one of his clients.  When we got together for dinner (and, yes, drinks) one of the topics (inevitably) was architecture.  Lately he has been working with some very large international companies re-architecting their public web sites to flexibly deliver localized content.  The solution was to combine Service-Oriented Architecture with Web Content Management.

In a nutshell, the architecture includes a web front end that is composed from portlets where each portlet requests content from WCM system(s) using WSRP.  The front end is de-coupled from the WCM systems via a service bus where the service bus is responsible for routing the content request to the appropriate WCM system.  (I’m using the term “service bus” here in the most generic sense, not to denote a specific product.  My friend prefers the term “service fabric”.)

This has an obvious advantage for localized content.  The service bus routes the request to the correct WCM system based on the chosen local.  This allows each division, country, or geography to manage its own content yet the corporate web presence is still unified.

Another advantage my friend pointed out is that this architecture simplifies previewing of new or modified content.  The service bus can route content requests to a staging WCM system for users that are responsible for reviewing new or modified content.  The new/modified content can be viewed directly in the production web site before being “published”.

It figures that I’d have this conversation *after* writing the ORA User Interaction document (a part of ITSO).  Nonetheless the ORA User Interaction document does cover these topics albeit not this specific usage.  This architecture is a specific example of what is denoted generically as “federation” (e.g. section 4.2.3) in the document.

Tuesday May 17, 2011

It's not the Journey, It's the Endpoints


[Read More]

Incremental Progress in (EA) Strategy Execution

I hate watching sports. Period. Except curling where I am confused yet fascinated all at the same time. Despite my aversion, I can still see lessons for EAs and those executing strategy. So here goes...

Consider soccer and (American) football. In soccer, patterns and plays are improvised and executed very quickly. Goals are scored when you put the ball in the other team's goal. You run until you score, get hurt, or just pass out. That's about it. In football, plays are thought out, deliberated by an overstaffed sideline, and then executed. Incremental progress is measured in yards and downs. At some point, someone either kicks a field goal (3 pts) or moves the ball into the end zone (6 pts). The game moves slower and more deliberately than soccer. This is where I see the lesson.

Regardless of EA methodology or framework, one needs to construct some sort of roadmap for their architecture. Otherwise, all those massive architecture diagrams are nothing more than 21st century art. The roadmap articulates the various steps an organization needs to execute in order to reach a target state in the architecture. There may be multiple target states before arriving to the next "future state". And within each target state there are incremental steps. Sometimes, its baby steps, and that is OK. 

To paraphrase a previous tweet or blog post, EA (strategy execution)  is a set of executed tactics orchestrated to achieve a desired end state. EA programs should take great care to crisply define the target states and the incremental tactics used to achieve each target state. And, when those tactics or states are realized, examine closely if one is still on track and is moving forward. I always advocate the value of  "advancing 1 yard" on a project or other initiative regarding the architecture. 

Sometimes, a yard is all you can get. Take it, and keep moving.

Monday May 16, 2011

Enterprise Climatologist?

Some of us on Twitter (#entarch) were noodling around for alternative names for Enterprise Architects. Someone chimed in about using "meteorologist" and suggested "climatologist". Then I thought more about the definitions of these words and how these roles operate.

These individuals work on massive amounts of historical data and seek patterns in nature to predict weather patterns and then issue forecasts. But at this point, the best we can do is react to the coming weather. If its a tornado, we head to the SW corner of the basement. If its a hurricane, we try to get out of town (at least most do). We cannot stop a tornado or steer it in a more favorable direction. And while there are proactive measures one can take to endure a storm and bolster structures, one cannot control or shape the weather. 

And that is where the meteorologist/climatologist analogy breaks down for EA. EAs need to be strategic in their thinking and help clients shape their future, not solely react to enterprise events. Like the weather, there are forces (e.g., Porters Five Forces) that one cannot control and must formulate a response. But the EAs job is to provide a vision and executable plan to a desired end state. Smart EAs leverage the experiences of others in design patterns and strategy execution. The discipline of EA provides the way to proactively shape the future for an enterprise. 

What are your thoughts? What lessons can EAs and the discipline of EA garner from other disciplines?

Tuesday May 10, 2011

Studying for TOGAF Certification

As I study for my TOGAF 9 certification, I am impressed with just how well thought out it is.  Granted, there is more information than the average EA will need for any single/particular gig, but it sure is extensive.  While the certification test is very detail oriented (you really gotta know your stuff to pass), I am also looking at it as a way to refine my approach to EA.  TOGAF is very often modified to fit an organization's particular needs and the scope of the EA activities, but it can also serve as the whetstone to sharpen one's-own EA sword.

So, while I am going over the TOGAF specification line by line, chapter by chapter in order to pass the certification exam, I am keeping in mind that it's real value is as a framework and a reference.  If you are about to engage in, say, data architecture or security architecture...what are the things you should be looking for?  What are the key deliverables?  These are all things that are at your fingertips in the TOGAF 9 spec.

Monday May 09, 2011

Architecture in 4 Slides

I think Bruce's idea on an Architecture in 4 Slides is the right idea for presenting such material at the executive level. Often times the C-level crowd does not have the time, nor should they take the time, to digest all the details of the full architecture description. At the end of the day, the executive wants to know "how do I get to the future state". This usually means going to the fourth slide that describes the roadmap.

I started doing some math, though, and realized that Bruce was only talking about Enterprise Technology Architecture. For those who think in TOGAFian terms, we have three other domains to describe. And maybe a 4-pack of slides each for security and SOA. So unfortunately the executive deck grows 4 slides at a time. But I think Bruce's idea is still sound. Each domain gets four slides.

I think this approach is good for the boardroom. I think this executive deck is a derivation of more detailed models. Those who need to plan and ultimately implement the architecture need more detail. I've contended in other forums that one picture is insufficient to describe. One needs multiple views of an architecture (segment) in order to fully understand it. Secondly, pictures alone are insufficient. A description of the elements and rationale for decisions made is essential to make the architecture description actionable. I'm thinking of the standard formerly known as IEEE 1471 which advocates for multiple views based on the stakeholder and their concern(s). We the architects need to consider the audience of our work and tune it accordingly. This means multiple versions, levels, of detail, and notations perhaps to make our points.

Getting out in front

Got a link they other day from an EA colleague on Martha Heller's recent post Making EA Matter. As an EA I liked the quote about the EA being the smarted person in the room and the least arrogant. We could psycho-analyze our staff to ensure they are the correct Myers-Brigg type for the job. At the end of the day, are all those pretty pictures actionable? Can the architect take the grand vision and decompose it into executable steps? Yes, and even go as far as building a notional WBS.

I really liked point #4 about getting in front of projects. Having spent time establishing governance processes and as a solution/project architect I can tell you this can relieve much pain in an organization. The amount of project-level architectural food-fights can go down dramatically. Wire the EA into the front-most part of the organizational processes. Get it linked to the corporate strategy, PMO, and RFP processes is key. Getting an EA a seat at the PMO table is even better. EA gaining visibility into the contract creation process (as opposed to right before the CIO signs the contract) reduces deviations, waivers, and other downstream battles.

Tuesday Mar 22, 2011

The Power of Knowing Where You Are Going

[Read More]

Tuesday Feb 22, 2011

The (non) Importance of Language

[Read More]

Monday Dec 13, 2010

IT Strategies from Oracle – Great EA Library

[Read More]

Monday Dec 06, 2010

ITSO - Behind the Scenes

[Read More]

Sunday Nov 28, 2010

EA Governance - Architecture's Sustainability

[Read More]

Art, Artifacts, and Best Practices for Enterprise Architects


« October 2015