Thursday Jul 14, 2011

TOGAF Certification

Well, I am one week away from going for my TOGAF certification.  For those who are also going for your certification and want some additional prep, I found two sets of additional questions for Part I and Part II (scenarios) of the test.  Check them out - good questions.

Tuesday May 24, 2011

Its always about the business (or mission)

So yesterday the follow-worthy @chrisonea lobs this question on Twitter:

Is there any circumstance under which IT should build a thing without a business purpose?

I emphatically answered, NO. Here's why.

Long ago when the last of the punch card machines were dispatched to the junkyards and the IT department was still called Data Processing, I was in college. Being an IT wannabe, I enrolled in my first COBOL course. Dr. Barone was my instructor and took us through all that verbose quasi-English that produced reports on green bar paper in the lab. Aside from COBOL, he taught us a bit about the relationship between the business and IT. IT, he contended, exists to serve the business and not the other way around. He was rather emphatic about it. We were not at liberty to code our hearts out like some painter with a canvas. We were to fulfill requirements. Nothing more. Nothing less. Sir, yes sir!

This idea has always stuck with me. Whether working in internal IT departments or producing software for external clients. Even in the latter case the software exists solely to achieve an objective for the client's business. It especially resonates well as I focus on enterprise architecture. 

If I were to rationalize an IT portfolio of applications or middleware, I still rationalize at the behest of the business. There is a realizable benefit that can be articulated in business terms. Reduced operating costs through simplification in this case. Every CFO and CEO understands that language. Even if I were to "build it and they will come" (speculation), there would still be some business outcome I'm seeking such as revenue generation.

Yes, ITs still about the business. Period.

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


« July 2016