Eric Stephens

Basic is Best

by

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

New Papers from the OEA Practice

by

I wanted to make you aware of  several white papers recently authored by my colleagues here at Oracle. I hope you find them helpful in your own EA related activities.

Lessons Learned in Large Scale Transformations by Hamidou Dia.&nbsp…

Tools of the Trade

by

So recently my buddy over at OTN Bob Rhubart asked, “What tool or tools are indispensable in your role as an architect? When faced with a new project what’s the first thing you reach for? Why?”. I instantly protested regarding the brevity of the a…

Tools of the Trade

by

So recently my buddy over at OTN Bob Rhubart asked, “What tool or tools are indispensable in your role as an architect? When faced with a new project what’s the first thing you reach for? Why?”. I instantly protested regarding the brevity of the answers. He suggested I blog about it. So here goes.

So the Miss America answer is I “reach” for my eyes and ears. Listening to the customer’s needs and pain points is vital to ensuring a resultant architecture is in alignment with their business objectives and is attainable within their cultural milieu. I need to approach each engagement or initiative with a fresh, clean slate and record everything I hear or see. I can’t help but liken the job to that of an archeologist or crime scene investigator – especially when focusing on current state architecture.

For practical tools I look to a metamodel to determine what type of information am I trying to collect. It depends on the corporation or framework I might be working with, but the metamodel provides me a sense of completeness in what I’m looking for. Its a great way to catalog current state observations and look for trends, redundancies, and sub-optimizations. When creating a set of future state renderings, it allows me to parse out future capabilities and map them to goals, drivers, and other objectives.

So how do I track this information? I use Excel to track catalogs and matrices of the information in the metamodel. Optimally I would pump this information into a repository-based EA modeling tool like Troux, or MEGA. But not all EA programs have made the leap to these tools – many are still relying on PowerPoint/Visio (or OmniGraffle for us Mac folk). If I really need to do some extensive analysis – and its happened at least once – I’m able to export to CSV files and put them in a database and use my SQL-fu to come to an answer.

As digital as I have become with an iPhone, iPad, and MacBook, I still rely on a bound notebook for taking notes – especially during customer conversations. The linearity of (spectacular) programs like Evernote, OmniOutliner, or even MindMap Pro just doesn’t work for me during discovery sessions. The information is not in a linear outline. I need to draw arrows all over the place. I need to instantaneously switch back-and-forth between writing text notes and drawing pictures. And batteries will eventually die or the flight attendant will bust me during takeoffs and landings…

So there you go. A metamodel, Excel, and a good notebook. That’s my answer, Bob, and I’m sticking to it.

Its always about the business (or mission)

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

Incremental Progress in (EA) Strategy Execution

by

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.

Incremental Progress in (EA) Strategy Execution

by

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.

Enterprise Climatologist?

by

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?