Inside Architecture

Notes on Enterprise Architecture, Business Alignment, Interesting Trends, and anything else that interests me this week...

August, 2007

  • Inside Architecture

    IBM comes around, agrees with Microsoft on SOA


    David Linthicum pointed out this gem from IBM's Bobby Wolfe that admits, openly, that you cannot buy a product and then, magically, get a SOA out of it.  Hooray!  Microsoft has been trying to tell people for years that SOA is not a product, it is a way of building

    The fact that this message is coming from Bobby Wolfe, co-author of the landmark book Enterprise Integration Patterns, is indicative.  Common sense is much more refreshing than marketing noise. 

    Wolfe goes on to explain what you get when you buy a product without thinking about SOA:

    "The problem is this: An ESB by itself produces no business value. An ESB is a means to an end, not the end itself. An ESB is like the electrical wiring or plumbing of an SOA. Plumbing does not produce value; sinks with water coming out of their faucets do. Wiring does not produce value; lights, especially lights connected to switches, are valuable. A road is not valuable except that it enables you to get from one point to another. An ESB without an SOA is like a road from someplace nobody is located going to other places nobody wants to be. People might eventually want to go to those places, but in the meantime, the road is all cost and no benefit."

    Bobby Wolfe calls this style "ESB-Oriented Architecture," a term that David Linthicum warns is "not an Architecture."  To quote David Linthicum:

    "The truth seems to finally be coming out…you can't buy a SOA. Indeed, SOA is something you do, and an ESB is not an architecture, it's a mere instance of technology."

    I agree with David Linthicum on this.  There is no such animal as ESB-Oriented Architecture.  So while I'm pointing out the strengths of this article, let's all agree not to create a new term from this one.  If I see a powerpoint with the acronym EOA on it, I'm leaving the room!

    SOA never was something you could buy.  You have to change the way you write software to build an Enterprise SOA. 

    Building an Enterprise SOA is a very different task from building a single application with a nice web services layer... that you can do without rocking the world, and a lot of folks have done it, but that's not what I'm alluding to.  I'm convinced that the real payoff comes from building for the Enterprise, and that means understanding your shared, or canonical, data model.  That means understanding your business objects and events.  

    Enterprise SOA requires management frameworks to rationalize your portfolio, and process changes to fund your projects in a way that encourages the creation of specific services, a well-run Enterprise Program Management Office (EPMO) for insuring that governance occurs and that quality is high, and a functioning Enterprise Architecture team that allows you to bring the information together, and evangelize it's use.

    Buying an ESB and hoping for a SOA is like going to Home Depot and buying a truckload full of random building supplies, dumping them on an empty lot, and hoping someone will build a house from it. 

    You can buy bits of technology, but if you approach this problem with technology first, you will fail.  Bobby Wolfe agrees.

    The mindset is often: “We don’t know what else we need, so for now we will just build an ESB.” But is this really any different than the approach of “You start coding, I’ll go find out what they want”?


  • Inside Architecture

    When they are not ready...


    Leadership is a funny thing.  You cannot lead someone to where they are not ready to go.  You have to lead them to where they are able to go next.

    Blanchard calls this "Situational Leadership."  It is up to a leader to be able to evaluate where someone is, figure out the steps to get them to a point of excellence, and then help them to take the first step. 

    For example, let's say I want my son to be an accomplished swimmer.  I can say "Dive in and give my a lap with a breast stroke and a lap with a backstroke".  I can say it... but if he can't swim for 10 feet in a row, and his breast stroke is more of a flailing thrash, then my request will not produce the desired result.  I will have taught him nothing.  He will be frustrated and resentful.  Nothing positive will occur.

    On the other hand, if I ask him to show me where he's at, and I explain that the next step is to work on his breast stroke, and we are going to take it slow... then both of us feel a lot better and he makes one more step towards becoming an accomplished swimmer.

    Why the analogy?  Because the same thing works for teams and departments and organizations.

    If you have a team of mainframe CICS developers, good ones, throwing them into a SOA implementation may be a stretch.  Or maybe not.  CICS is really a message-based mechanism, and if that team is used to developing their systems from a message-oriented approach, then you are simply teaching technology, not entirely new concepts.

    You have to ask them to show you where they are at.  You have to evaluate, ask questions, find out what they do well.  You have to perform that 'skills gap analysis' before you can begin to take a person, a team, an organization down the road.  And then, you can't ask for the full lap with the breaststroke if that is not what the are able to do. 

    Lead from the place where your follower is standing.  You cannot successfully lead from anywhere else.

    This is not a technology problem.  This is a human problem.  But in Enterprise Architecture, it is tempting to assume that every technology can be considered, because, of course, "it's just software and we know software."  That's bizarre.  It's like saying "everyone can do anything."  To make it worse, if we ask the developers, they will say that bizarre assumption is true, even when it is not.  That really throws the notion of personal accountability out the window, but it is typical of software people. 

    Let's say you need to create a roadmap.  The domain is something small... let's say property management.  ("Small" in that, for most enterprises, there are not a laundry list of integration points).  Let's say you, as the architect, have led a process to pick a good commercial package.  You find a nice application.  (We will call it "Propman").  It has the features your business wants.  It has a secure, reliable, scalable architecture.  It even has web services.   That's good because your financial system also has a web service interface.  No one uses it yet, but Xavier, one of your team members, keeps telling you that he's dying to try "doing SOA work."

    Do you propose a roadmap that shows data integration from the "Propman" app to the financial system using web services? 

    Maybe.   As long as you have evaluated Xavier and you are absolutely certain that he is up to the challenge.  Odds are, he's not.  It is more likely that he's read about SOA in a magazine and he's eager to try... or he wants to improve his resume and bolt for the door.  Your roadmap is incomplete because the technology is possible, but the people are not ready. 

    Architectural roadmaps have to take things into account that extend far beyond technology.  They have to take into account things like corporate culture, technical readiness, local availability of talent, financial implications, deadline implications, strategic directions, company policies and, yes, company politics.  These things will affect your choices.  They must.  You have to lead the organization from where it's at, not where you wish it was at.

    A close advisor told me the other day, "be aware of your radar... keep it turned on."  Look for all angles that may influence the potential success of your domain roadmap. 

    If you look only at the technology, you may miss the fact that the team is not ready to use it. 

    And that is one way (of many) that projects end up under water.

  • Inside Architecture

    Enterprise Architect: Breadth, Depth, and Interchangable Parts


    Alan Inglis has posted a second time about the need for an Enterprise Architect to be oriented more towards breadth than depth.  I agree but I feel the squeeze.

    Enterprise architecture is there to bridge business and IT concerns.  Therefore, they need to be talking to business representatives and business leaders to build trust, listen to strategy, offer insight and ideas, and clarify requirements.  They need to be talking to IT architects and leaders to build rapport, deliver actionable plans, influence, and sometimes, enforce.

    As you become more immersed in the EA role, you begin to lose your technical depth.  I haven't coded significantly in two years now.  There are technologies that I understand but have not coded.  That is good (to a point) and bad (to a point). 

    If our industry were more mature or if the rate of change was more moderate, I would not need to code to keep up.  But it isn't.  Our industry is changing daily, and there is no widely available model to allow an architect to understand a new technology quickly without experiencing it directly.  There is no standard parts mechanism that drives people there, and therefore, no economic incentive for vendors to publish their products with model elements that would allow an architect to make direct comparisons in any kind of depth.  Marketecture rules.

    And therefore, the Enterprise Architect is limited.  We can never get far from the level of technical depth required to deliver decisive insight, yet that heavy burden of constant learning prevents us from being able to reach up to a higher level of business effectiveness.  The fact that we are a hybrid means that we can neither job terribly well. 

    And that, I think, is long term, the biggest reason why we are not often enough seen as valuable.  Both sides (Business and IT) can produce someone who knows their side better and deeper than the EA.  In a cooperative environment, it won't matter.  But in many IT shops, there's not enough cooperation to butter one side of a piece of toast.

    There is a way out, but it is long term.  We need to get a consistent taxonomy of systems and features, make it available, have the vendor community contribute to the definition of it, and then provide incentive for them to map their own commercial systems to it.  Then architects can make the comparisons they need to make without needing a direct and deep engagement with every new technology. 

    That's the transition to interchangable parts.  That won't be easy.

  • Inside Architecture

    Leadership vs. Management


    It is often said that if you are in a group of explorers hacking through a thick jungle, the manager is worried about cutting a straight and efficient path, while the leader is climbing the trees to make sure that you are goin in the right direction.  Fact is, you need both.

    When I describe architecture, sometimes I need to lead.  Sometimes it is about insuring that the direction is the right one.  I need to make sure that we are keeping the correct things visible as the goal, and staying focused on the elements that will get us there, while staying tuned to the "snares" that would prevent progress.

    Other times, I need to manage.  I need to write the document, create the diagram, lead the team meeting, enter rows in the schedule.  It's day to day, block and tackle stuff.  It's taking my turn at point.  It is not creative, but it is necessary.

    This distinction applies whether you have direct reports, or you are in a position of influence (as I am these days).  The rules really aren't different, even though the balance of motivations are. 

    The toughest part, really, is knowing when to lead and when to manage. 

    I have no real 'formula'.  I will say this: normally your team will tell you.  The key is to listen.

    Your team will tell you if they feel blocked, or confused, or if they have flipped the bozo bit on someone.  They will tell you if they need help... if you know how to listen. 

    Listening is an art.  It means not only hearing status reports (or excuses), but digging deeper to understand priority conflicts or to detect gaps in tools, abilities, or confidence.  It means knowing when to express support and when to offer alternatives.  It requires patience, insistence, and, as often as not, silence.  Listening means going beyond the "what" to get to the "why," and then to push to the "why not?" 

    I spent a few years as a manager.  I'm no grand expert.  I will say this: to decide whether you need to lead or to manage, the key is to listen.  

  • Inside Architecture

    Actionable Enterprise Architecture through Feedback


    This is my third post on Feedback loops and EA.

    At the Gartner EA Summit in the spring, I was chatting with some folks at lunch, and the question came up: what's the biggest criticism of EA in your organization... and the answer was nearly unanimous: "your models are great, but we can't really use them when building systems."  In other words, EA is not actionable.

     I've been thinking about this one a lot.  As I build out the Integration area, I'm trying to avoid the stain of "non-actionable EA" by directly engaging with the project teams.  But direct engagement isn't enough.  There has to be a feedback loop.

    Traditionally, EA teams will go off and create a set of models that describe how the world should look.  There may be some strategy in there, as well as some wishful thinking.  When the project teams get going, we hand them our work and say: here's your shiny solution!  They thank the EA politely and then get around to building an app that doesn't take the EA models into account at all.

    The IT teams get no value out of EA. 

    This engagement model has to change.  The IT teams have to have skin in the game.  The good men and women building our systems need to feel ownership of the EA models.  They need to feel like those models represent their interests, and carry their career forward.  They need to be incented and rewarded through the connection with EA models.

    Today, in many organizations, including my own, this rarely happens.

    I can see the need for a number of feedback loops:

    1) Models.  The first loop needs to take models into account.  When the EA team comes in with a model and the IT team ignores it, it was not valuable.  If the IT team comes in with a model and the EA team ignores it, same thing.  Both behaviors must change.  But if both sides keep pointing fingers saying "that guy has to change first" then we are no better than schoolkids fighting in a playground.  Someone has to be the first to own up.  I believe it should be the EA team that starts by accepting feedback from the IT teams.  That starts with models. We need to take our models, compare them to the models of the IT teams, and where they differ, we need to work with the IT teams to figure out what needs to change... in the EA model.   This includes data models, reference architectures, and taxonomies.

    What parts of their design really are "enterprise?"  I doubt anyone asked most IT teams that question, and they get to try to answer.  With a few rounds, we can create a good answer, and I'll bet that the part we agree on, will be the most stable part of the design.  The IT team will buy in.

    2) Participation.  The second loop is one in which we measure the relevance of our communication processes by looking at how each team participates with the other teams.  Who comes to one another's meetings?  What ideas are shared?  What decisions are made?  In order to develop a feedback loop, folks have to actually speak with one another.  They need to participate in the success of one anothers' projects.  This participation builds trust and connects the most important, and the most difficult, type of integration: between people.  This kind of peer-to-peer feedback crosses in many directions.  not just EA <--> Solution Arch, but also Solution Arch <--> Solution Arch. 

    3) Incentives.  Once a year, in our organization, every employee comes before their manager for a performance review.  The process is fairly involved, and there is a lot at stake.  In Microsoft, stock awards and cash bonuses ride on the results of your performance review, and employees will work very hard to make sure that their review looks as good as possible.  If part of that review process includes being rewarded for participation, involvement, and consumption of models from other teams, then the behavior will occur more frequently.  Of course, and organization can tie itself into knots if EVERYONE is supposed to reach out to someone else before getting anything done.  Striking that kind of balance is difficult, but not impossible.  Regardless of difficulty on the management side, getting incentives in place to encourage the right amount of cross-team collaboration will go a long way towards creating the kind of interdependency that is necessary to make Enterprise Architecture actionable.

    At the end of the day, Enterprise Architecture is not a team or a set of models.  It is a system of interacting variables, people, incentives, and relationships.  We all have to believe that the goal is worth pursuing, and our management has to support us in pursuing it. 

    With feedback, EA can become actionable.  Without it, I cannot see it happening.  EA is a culture shift.  Until folks make the shift, EA folks are going to struggle with the bars of the ivory tower where their organization locks them away.

  • Inside Architecture

    Agility, Feedback, and Enterprise Architecture


    I blogged a few days back about agility in EA: Deliver Early, Deliver Often, Take Feedback, Iterate. 

    I've said often that this concept is just as applicable in business as it is in technology. 

    Enterprise Architecture is supposed to be the bridge between business and technology.  Let's think about the concept of a bridge for a minute: we take changes on one side and translate them into changes on another. 

    Can that work both ways?  Most of the time, the descriptions are one way: we take changes in business and translate them to technology, but I believe that we lose value if we Don't take changes in technology and translate them to the business.

    That's an easy thing to say, because there are two definitions of 'technology.'  If we talk in generalities (technology trends, new capabilities, new threats, new opportunities), then taking technology to the business is the job of IT and the CIO anyway.  That is very important, but not what I'm getting at.

    There are innovations that occur deep in the bowels of IT that stay there.  They never come back to be visited, or understood, or reused, or leveraged, in the business.  That is because the business, in general, has no way to get that feedback.

    An example would be good.

    For a while at Microsoft, I worked with the Legal IT division.  Their charter: provide tools to the lawyers and paralegals in the corporate law department.  They had tools for discovery and document management and workflow... but no tools for clause management.

    Clause management allows attorneys to compose legal documents from pre-written 'template' clauses.  With a clause management tool, you create a workflow that creates these clauses, and you can update them in all downstream document templates by updating them in the clause management tool.  No more situations where a contract is signed using 'old' clauses when 'new' ones should be used.

    Clause management is something that attorneys want, but never get around to paying for. 

    That said, as I moved into Enterprise Architecture and started looking at tools used by other parts of the Microsoft business, I found three clause management tools.  Not one of them was written by the legal IT team.  Most of the attorneys had no access to them.  They were used by the business teams to keep track of the clauses that the attorneys had approved so that a new contract could be created quickly.

    In Enterprise Architecture, we want to be able to tell the Legal department that a team, in the company, wants to build a clause management tool.  Not only can they vet the requirements, but we can make sure that the resulting tool would be useful to the attorneys for many other businesses.  In other words, actually connect the tools to the users who should be using them, not just the ones who are paying for them.

    And this is one place where Enterprise Architecture can help.  By mapping the features of a new system to a consistent framework that we call 'Solution Domains,' the Enterprise Architecture team is able to draw attention to the fact that a new project (or an existing app) meets needs in many areas.  We can see overlaps before they happen, and overlaps that already exist.  We can get the right constituents into the room and make sure that the correct voices are heard.

    This is a form of 'feedback' in the same agile sense.   Our customer is the enterprise.  It is an odd organism... completely capable of performing excellent work in one area, that another area is oblivious to.  When the enterprise asks, Enterprise Architecture needs to be there to bring people together, get the innovations surfaced, and develop tools that everyone can use.

Page 1 of 5 (27 items) 12345