Tuesday Dec 04, 2012

Basic is Best

Fellow foodies will recognize the recent movement towards "farm-to-table" restaurants. These venues attempt to simplify their menus and source ingredients as close to the source as possible. I had the opportunity to dine at such a restaurant the other evening. I was gushing about the appetizer to my server when she described the preparation for the item and then punctuated her comments with "basic is best". I reminded my fellow enterprise architect diners there was an architecture lesson in that statement. They rolled their eyes and chuckled. But they also knew I was right.

I'm reminded of Frederick Brooks' book The Mythical Man Month and his latest The Design of Design. The former must read book talks about complexity. But he refrains from damning all complexity. The world we live in and enterprises we strive to transform with enterprise architecture are complicated organisms, much like the human body. But sometimes a simple solution is the best approach. Fewer applications (think: portfolio rationalization). Fewer components. Fewer lines of code. Whatever level of abstraction you are working at, less is more.

I'm reminded of the enterprise architecture principle "Control Technical Diversity". At one firm I created pithy catch phrases for each principles. I named this one "Less is More". But perhaps another variation is what my server said the other night, "Basic is Best".

Monday Oct 03, 2011

Enterprise Architecture Tools; Another View


Eric Stephens, my friend, and fellow Oracle Enterprise Architect, recently blogged on the subject of “Tools of the Trade” of Enterprise Architecture.   I was invited to the same podcast as he was, but could not attend.  So, in absentia, I thought I’d add my two cents to his sage post:


There are several very good EA tools on the market, but each come with their own learning curve and, as Eric mentioned, there can be variance in usage across companies - ranging from no standardized EA-specific tools to adoption of one such as Troux.

Having said that, here are the tools that I think are basic / fundamental in an Enterprise Architect’s tool box and how they can be used (or at least how I use them).  Idea is to embrace, but extend what Eric said.



Spreadsheet (such as, but not limited to Excel)

Capturing everything about the project such as organization structure, divisions, current costs, etc…).  Once it is in the spreadsheet, it can be sliced and diced and, importantly, imported into the presentation software to make clear the facts that went into the current/future state positioning.  Also key to making a business case for any initiatives to be undertaken.

Presentation Software (such as, but not limited to Power Point)

Communication, communication, communication!  Getting everyone on the same page through information roll-ups, diagrams and architectures is really at the heart of what we do.  Yes?

Oracle JDeveloper / BPM

This is great for sketching out a business process in BPMN notation which (unless you NEED a L0 – L2 model) is a pragmatic way to flesh out current and future state business flows.  The added benefit is that, with Oracle BPM 11g, Business Analysts and Developers can begin to collaborate on fleshing out your model once a business process automation project gets the go-ahead.

Sure, you have to download a development environment but, hey, it’s free and relatively easy to use tool.

Whiteboard Markers (such as, but not limited to Expo markers)

Nothing works better than getting people in a room and working through a particular topic in a collaborative fashion.

Hint from personal experience: make sure they are dry erase and not permanent. 

Well organized file system (such as, well…you get the idea)

The more you do this stuff, the more you have a library of tried and true materials that are battle tested.  Try to organize them well on your disk (or do what I do and catalog things in a spreadsheet with hyperlinks  to the files – one of my secret tricks)

So, that is my story.  But, I may likely not stick to it....

Thursday Jul 28, 2011

TOGAF Certification - more


I have been getting a lot of questions about how to get ready for TOGAF.  The 2 previous entries have some good advice about training classes and how to study.  I will add (and reiterate) that the single best thing you can do after taking the training class is to

1) get the book and read it over and over so that you go from familiarity to really knowing the material (I found the physical book better for studying than the electronic book).  The smaller study guide was not of as much use  other than the fact that it summarizes things well.

2) get the sample tests and quiz a “study buddy” back and forth.  My buddy and I blasted questions over instant messaging while we were on the phone talking over our answers

Hope that helps (more)

Tuesday May 17, 2011

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.


Art, Artifacts, and Best Practices for Enterprise Architects


« July 2016