Tuesday May 17, 2011
By Eric A. Stephens on May 17, 2011
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
By Eric A. Stephens on May 16, 2011
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
By Pat Shepherd on May 10, 2011
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
By Eric A. Stephens on May 09, 2011
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.
By Eric A. Stephens on May 09, 2011
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
Wednesday Mar 16, 2011
By Pat Shepherd on Mar 16, 2011
Tuesday Feb 22, 2011
Monday Dec 13, 2010
Sunday Nov 28, 2010
Wednesday Nov 17, 2010
By Peter Heller-Oracle on Nov 17, 2010
Thursday Nov 04, 2010
By Pat Shepherd on Nov 04, 2010
Thursday Sep 16, 2010
By Pat Shepherd on Sep 16, 2010
Art, Artifacts, and Best Practices for Enterprise Architects
- Is Database-as-a-Service in your IT Services Catalog?
- An Agile Enterprise Architecture (EA) Delivers Critical Business and Mission Agility
- Soft Skills, Leadership, and now Empathy
- TOGAF Study Help - iPhone to the Rescue (perhaps)
- RACI Matrices, EA Charters, and Surgical Suites
- Basic is Best
- BPM Process Accelerator Packs - Update
- Current State EA: Focus on the Integration!!!
- Even EA's Have Bad Days - it's Time to Reset
- The Application Architecture Domain