7 years, 10 months ago

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”.

7 years, 10 months ago

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”.

9 years, 19 days ago

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 abs…

9 years, 19 days ago

Enterprise Architecture Tools; Another View

Tools

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:

(http://blogs.oracle.com/enterprisearchitecture/entry/tools_of_the_trade)

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.

Tool

Use

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….

9 years, 2 months ago

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 taki…

9 years, 2 months ago

TOGAF Certification – more

TOGAF Books

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)

9 years, 5 months ago

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.

9 years, 5 months ago

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.

9 years, 5 months ago

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?

9 years, 5 months ago

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?

9 years, 5 months ago

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 …