Tuesday, October 4, 2016

"How will Enterprise Architecture help my retail stores make their sales goal this month?"

As an Enterprise Architect, I have often been asked questions like the one that entitles this post. Business executives, wary of EA in the first place, want to understand what value it brings. They will sometimes try to get this understanding by asking how a strategic endeavor like EA provides a tactical benefit like the one most important to them at the moment, but this is the wrong kind of question to ask. Enterprise Architecture is strategic in nature, and strategy affects an enterprise at a higher level, more profoundly, and in a way that can provide far more value than tactical decisions. Imagine an executive asking these questions:
  • What is the connection between developing a mission statement and increasing product sales in Asia?
  • How does the development of business strategic objectives reduce inventory theft in our retail stores?
  • Why would I waste money on a master data management architecture when what I really need is to more easily and cheaply meet regulatory requirements? (It turns out there IS a direct connection here.)

Here is a real world example. I recently heard a veteran Enterprise Architect relate a story wherein he was working for Homeland Security on a project that deployed sensors throughout the US designed to detect harmful chemical agents. When the architect presented a plan to use the TOGAF Architecture Development Method to plan and implement data analysis tools to help better understand the collected data, the executive to whom he was presenting was nonplussed. He wondered why they would spend time and money on a strategic approach to understanding sensor data when those resources could be better spent on deploying one more sensor.

Of course well executed Enterprise Architecture efforts help an enterprise to achieve tactical goals, but the connection is not always intuitively obvious, and is often difficult to articulate in detail particularly when the EA effort is first being proposed. All of the questions in the bullet list above do have answers. 
  • A mission statement should express the values of the enterprise, and those values shape strategic goals such as increasing market share in Asia. Strategic goals help determine where budget is allocated and what tactical steps will be taken. 
  • Business strategic objectives are the highest level wherein inventory security will manifest. This, again, results in policy formulation and funding that are necessary to implement inventory security tactics. 
  • A master data management architecture is essential for enterprises with multiple sources of customer data, and facilitates fulfillment of "Know Your Customer" regulations. 
As Enterprise Architects, part of our job is to clearly articulate the value of doing EA. When we are asked how a strategic endeavor will result in tactical gain, we should be prepared with an answer that presents that value as clearly as possible, but should also point out that good strategy always leads to better tactical opportunity. 

"How will Enterprise Architecture help my retail stores make their sales goal this month?"

As an Enterprise Architect, I have often been asked questions like the one that entitles this post. Business executives, wary of EA in the first place, want to understand what value it brings. They will sometimes try to get this understanding by asking how a strategic endeavor like EA provides a tactical benefit like the one most important to them at the moment, but this is the wrong kind of question to ask. Enterprise Architecture is strategic in nature, and strategy affects an enterprise at a higher level, more profoundly, and in a way that can provide far more value that tactical decisions. Imagine an executive asking these questions:
  • What is the connection between developing a mission statement and increasing product sales in Asia?
  • How does the development of business strategic objectives reduce inventory theft in our retail stores?
  • Why would I waste money on a master data management architecture when what I really need is to more easily and cheaply meet regulatory requirements? (It turns out there IS a direct connection here.)

Here is a real world example. I recently heard a veteran Enterprise Architect relate a story wherein he was working for Homeland Security on a project that deployed sensors throughout the US designed to detect harmful chemical agents. When the architect presented a plan to use the TOGAF Architecture Development Method to plan and implement data analysis tools to help better understand the collected data, the executive to whom he was presenting was nonplussed. He wondered why they would spend time and money on a strategic approach to understanding sensor data when those resources could be better spent on deploying one more sensor.

Of course well executed Enterprise Architecture efforts help an enterprise to achieve tactical goals, but the connection is not always intuitively obvious, and is often difficult to articulate in detail particularly when the EA effort is first being proposed. All of the questions in the bullet list above do have answers. 
  • A mission statement should express the values of the enterprise, and those values shape strategic goals such as increasing market share in Asia. Strategic goals help determine where budget is allocated and what tactical steps will be taken. 
  • Business strategic objectives are the highest level wherein inventory security will manifest. This, again, results in policy formulation and funding that are necessary to implement inventory security tactics. 
  • A master data management architecture is essential for enterprises with multiple sources of customer data, and facilitates fulfillment of "Know Your Customer" regulations. 
As Enterprise Architects, part of our job is to clearly articulate the value of doing EA. When we are asked how a strategic endeavor will result in tactical gain, we should be prepared with an answer that presents that value as clearly as possible, but should also point out that good strategy always leads to better tactical opportunity. 

Monday, November 17, 2014

As a customer, I asked for this 12 years ago. FINALLY!

I was consulting at Aetna at the time. .NET was an exciting new application development platform challenging Java for the hearts and minds of developers. But at Aetna, we ran our websites on high-powered Solaris boxes. In several training sessions delivered by Microsoft, I would ask "When will you provide a feature-complete Common Language Runtime for Unix?" I would get the same hem and haw with references to Mono later on. Finally, at one session, I said this:

So, I used to ask when you would provide a feature-complete Common Language Runtime for Unix, but I haven't gotten very far with that question, so let me ask you this. Why will you never, never, never, never, never, never, never, never, never, never, never, never provide a feature-complete Common Language Runtime for Unix?"


It went over about as well as you'd think, but I was really frustrated. Microsoft was supposed to be a software company. They were supposed to write the best software in the world. Portability was a big selling point of Java and the JVM, so why wouldn't they beat them at their own game?

Well, I was young(er) at the time and hadn't fully grocked the primacy of Windows at Microsoft and how Steve Balmer's focus was that every other product they had pushed the sale of Windows. I had given up on the idea of fully portable .NET applications. In fact, I hadn't even thought of it for years. Now, Microsoft has announced that, FINALLY, they will fully support .NET on Windows, Mac, and Linux, and there's more. Much of the platform is now open source. Check out Scott Hanselman's blog post for all the glorious, it's-about-time details.

Tuesday, February 11, 2014

When it comes to methodologies, maybe your karma should run over your dogma

"You must stand up during the stand up!"

"Excuse me, you may not talk in this meeting, you're a chicken, not a pig."

"We don't start work until the requirements are signed off."

“If it’s not on the board, we’re not doing it.”

If you've heard, or said, any of the above phrases then you've likely experienced methodology dogma. Methodology dogma is a strict adherence to the rules of an application development methodology in the belief that, if the rules are kept religiously, the project will be a success. But is that true? Are methodologies the answer in and of themselves, or are there more important factors to consider such as developer skill level or cohesiveness/chemistry of the team? This blog post from The Typical Developer suggests that, while best practices and methodologies have their place, they often become and end to a means rather than the other way around. 

Now, don't get me wrong. As an architect, I understand the value of good development best practices and methodology. In fact, I think they're indispensable for a highly productive IT shop, but they are only part of what makes a team productive. The problem that I often see is that when people get excited about a particular methodology, they sometimes focus on it as the sole answer to their delivery woes, and that’s never really the case. In IT, as in so many other areas of life, dogma is not man’s best friend.

Monday, October 14, 2013

U.S. Debt Ceiling Crisis Mirrored in Dev Shops with Technical Debt?

As the U.S. approaches the brink of defaulting on it's debt obligations, I am reminded of Ward Cunningham's metaphor of Technical Debt. Technical debt is the idea that, when we decide to develop an application "quick and dirty" to meet a deadline and knowingly bypass design and architectural decisions that we know will make the system more flexible/manageable/performant/etc., we incur a debt that we will eventually have to repay when we implement the designs later. The more we put strategic development off, the greater the debt becomes. The largest technical debt payments occur when we find ourselves embarking on massive projects to completely replace systems that have become dangerously obsolete.

Technical debt can also be use to rationally justify the quick and dirty approach if the value of meeting the deadline exceeds the debt incurred. Martin Fowler gives an excellent treatment of technical debt in this 2009 blog post. Cunningham himself gives a good video talk on the history and implications of this metaphor. Debt Metaphor - YouTube

What do you think? How is your dev shop doing with technical debt? How is YOUR debt ceiling?  

Thursday, May 24, 2012

"Enterprise Architecture" is Overloaded and Misunderstood

How do I know this? I am at the last session of Gartner's 2012 Enterprise Architecture Summit, and I have spoken with more than a few attendees who did not know what EA is. Now, to be fair, many of them were at the BPM conference just before this one and decided to sign up for the EA conference as part of a 4 day package, so EA wasn't necessarily their bag. Still, everyone knows what an application developer is. No one is confused about what an IT project manager does, or what is entailed in the job of a quality assurance tester. But somehow "architecture" and particularly "enterprise architecture" are ambiguous roles to many.

Enterprise architecture is not solution architecture at the enterprise level. It is not a purely technical role. Enterprise architecture is "the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise's future state and enable its evolution" (Gartner, Inc., 2012). EA is about bridging the gap between business strategy and IT investments. Enterprise architects model business capabilities for current state and target state, and develop sequenced roadmap waypoints to guide the implementations. We also map those capabilities to business objectives and principles. Our work helps executive leadership prioritize portfolio investments, set budgets, develop new products and retire systems. Try getting all of that out at a party when someone asks you what you do!

Gartner analyst Richard Buchanan has a rule I am going to try and enforce at my organization. No one should be allowed to use the words "architect" or "architecture" without a qualifier. Too often, I hear executives ask "what's our architecture for that?" where "that" can be anything from a technology to a product to a line of business to a delivery channel. What's our technical architecture? What's our solution architecture? What's our application architecture? What's our information architecture? All of those are fine questions for a variety of activities in an enterprise. But "what's our architecture?" has got to go.

Here's a diagram I put together showing some of the different architecture scopes, roles and deliverables for a typical solution implementation. Apologies to my information and data architect brethren for not including your role. Same for my infrastructure/technical architect friends. The scenario I described in my presentation did not call for you.