Deming’s 14 Points for Management and Team Development

by

Dr W. Edwards Deming’s work on quality control provided guidance for management and team development.  We reviewed Dr W. Edwards Deming’s work on quality control in Japan in one of my project management courses.  Deming is best known for his focus on quality and improvement.  Many of us are familiar with Deming’s Cycle for Improvement: (PDCA) […]

The post Deming’s 14 Points for Management and Team Development appeared first on Enterprise Architecture in Higher Education.

Context is Everything!

by

“Context eats strategy for lunch.” This quote is typically attributed to Peter Drucker, one of the most revered management consultants and business authors of all time, whose writings made significant contributions to the foundations of today’s business corporation. Most of us know this to be true . . . yet, we often ignore it in […]

Building planes in the sky

by

EA is like building planes in the skyEnterprise Architects are frequently expected to deliver large-scale enterprise transformation while keeping day-to-day business fully operational! This video sums it up perfectly:

Related posts:

  1. The Top 10 M&A Fallacies and Self-Deceptions The Top 10 M&A Fallacies and Self-Deceptions is another useful article…
  2. Enterprise Transformation – Open Group Conference Enterprise Architecture as Transformation has been my focus for many…
  3. More views on Enterprise Transformation The Open Group Enterprise Transformation Conference, in April 2012 in…

Business analyst? Business Analysis & Design On Steroids!

by

In a constantly changing world, with challenges for you as a business analyst ranging from big data, business intelligence/ analytics, BYOD and Lean/Six Sigma it is safe to say that business analysis is increasingly important for enterprise effectiven…

Categories Uncategorized

Its Been A Busy Summer

by

Wow, it’s been 2 months since my last post. I can’t believe it’s been that long. Things have surely heated up this summer . Outside of spending some quality R&R with the family, I have been extremely busy in three…

Categories Uncategorized

Ten Ways to Kill An Enterprise Architecture Practice

by

Have you seen practices that you know could kill an Enterprise Architecture practice?  I have.  A recent LinkedIn thread asked for examples, and I came up with my top ten.  I’d love to hear your additions to the list.

How to screw up an EA practice

  1. Get a senior leader to ask for EA without any idea of what he is going to get for it. If necessary, lie. Tell leaders that EA will improve their agility or reduce complexity without telling them that THEY and THEIR BUSINESS will have to change.
  2. Set no goals. Allow individual architects to find their own architecture opportunities and to do them any way they want.   Encourage cowboy architecture.
  3. Buy a tool first. Tell everyone that they need to wait for results until the tool is implemented and all the integration is complete.
  4. Get everyone trained on a “shell framework” like Zachman. Then tell your stakeholders that using the framework will provide immediate benefits.
  5. Work with stakeholders to make sure that your EA’s are involved in their processes without any clear idea of what the EA is supposed to do there. Just toss ’em in and let them float.
  6. Delete all the data from your tool. Give no one any reason why. You were just having a bad hair day.
  7. Get in front of the most senior people you can, and when you get there, tell them how badly they do strategic planning.
  8. Change your offerings every four months. Each time, only share the new set of architectural services with about 20% of your stakeholders.
  9. Create a conceptual model of the enterprise that uses terms that no one in the enterprise uses. Refer to well known business thinkers as sources. When people complain, tell them that they are wrong. Never allow aliases.
  10. Every time you touch an IT project, slow it down. Occasionally throw a fit and stop an IT project just for fun. Escalate as high as you can every time. Win your battles at all costs.

Your career will be short. 🙂

Enterprise Architects are more than “problem solvers”

by

One of the most common mistakes that people make about Enterprise Architects is the notion that we are problem solvers.  Yes, EA solves problems, but to frame EA in those terms is like saying that an ER Doctor is a bandage changer. 

To help clarify the distinction between a “problem solver” and an Enterprise Architect, I will illustrate the logical argument for both, and show their differences.

Problem Solver Enterprise Architect
Task: understand the problems and solve them Task: understand the opportunities for the enterprise to be better aligned to its vision and focus attention on them.

Methods:

  • Find people who know what the problems are, and ask them.
  • Look for root causes to those specific problems, narrowing focus to the ones that contribute to a desirable outcome.
  • Describe solutions to those problems

Methods:

  • Collect and analyze information to understand the organization.
  • Design the organization to meet the desired level and type of value delivery.
  • Design ways to change the organization and ask why they didn’t already change on their own.
  • Look for root causes and underlying challenges.
  • Focus attention on the obstacles that prevent normal mechanisms from addressing the problem.
Results: well understood problems that are commonly ignored get  solved (without addressing “why they were ignored”). Results: opportunities that no one wants to see or problems that people are afraid to solve are discussed and addressed.

 

The left column is what business analysis is for.  It is what solution architecture is for.  It is NOT what Enterprise Architecture is for.  I don’t care how good you are at doing the stuff on the left.  I don’t care how well it has worked for you in the past while working as an EA.  The “raison d’être” of EA is not to solve well-understood problems.  It exists to find out why the organization hasn’t seen the obstacles that actually prevent success, hasn’t removed them,  and hasn’t figured out how to cope with them.

Five blind men describe an elephant, each in different ways.  The EA is the sixth blind man.  He listens to the other five and says “the problem is not that an elephant is like a fan or a rope or a wall… the problem is that it is standing in the living room, and dropping large amounts of waste on the floor.  Problem solvers try to find a better way to feed the elephant and remove it’s waste.  Enterprise Architects asks why everyone is standing in the same room as an elephant.

Categories Uncategorized