Inside Architecture

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

November, 2010

Posts
  • Inside Architecture

    EA Leadership and Compromise: Sometimes, success is not what you think it will be

    • 0 Comments

    About a week ago, I blogged a short story about a fictional town that faced a problem, with two competing solutions.  There are many observations about life in corporate IT that I included in that story: how different people can end up competing when they should be working together, how ideas can get in the way of cooperation, and how leadership can change the landscape.

    The most important thing I’d like readers to gather from that story is this: sometimes success is not what you think it will be.  Success is often a compromise, needed to create a solution that all of the stakeholders can accept.  The reality is that there are often many solutions to a problem.  Each will have pros and cons, costs and benefits.  Each problem with have forces that play across it, and people who care passionately about solving it. 

    Success may not be the “perfect” solution, or even the one that has the best cost-benefit ratio.  Success may be the one that removes the most obstacles to implementation.  If the people who care passionately about one idea become an obstacle to another idea, then forward progress may simple stop.  Problems are not solved by infighting.  Half-measures rarely produce full results (as the parable demonstrates).

    In that case, success may mean “choose a compromise path that is neither idea, but fuses the best of both.”  I’ve seen this problem many times, and regrettably, I’ve seen it repeated.   Dueling ideas or visions or roadmaps… and nothing moves.

    Leaders must be careful.  There is a tight-rope to walk.  Leadership at the wrong time can stymie innovation.  Leadership at the right time can lay the course for success.  The most important thing that a leader can do is to resist the temptation to pick the winner.  They should hold their people directly accountable (“run ‘em out of town”) if they cannot compromise, give them a deadline, and step back.  If things don’t work, follow through.  Roll heads.  The next leaders to step up will quickly compromise. 

    Taking a side, on the other hand, cuts off the stakeholders at the knees.  It sows dissention and creates an environment where people will agree “on paper” but continue to disagree in practice.  This reaction, predictable as it is, is passive-aggressive at best and serves only to defeat the long-term goals of reaching a solution that everyone buys into.  Leaders who make decisions that foster a passive-aggressive response are not well advised on their own organizational culture.  If EA is to be a trusted advisor, we need to advise leaders to take actions that their own organization will swallow.

    EA’s take heed. Learn the moral of “the little town of Busit.”  Advise your leaders to behave like the mayor of Busit.  Encourage them to allow stakeholders to create an accountable compromise solution that serves all, even if the solution doesn’t look like the one that you, or the leader, expect it to.  Trusted advisors must earn trust.   Earn it by helping your leader to lead.

  • Inside Architecture

    The Little Town of Busit

    • 0 Comments

    Once upon a time, there was a little town called Busit in a valley, deep in the mountains.  Through the middle of this valley ran the river Menatz. The valley was fertile and the farmers produced bountiful crops of grain, vegetables, and fruit.  The livestock was well fed and the people had plenty.  However, every year, in the spring, the river floods, wiping out farms seemingly at random on either side of the river.

    One the east side of the river, the people responded to the annual floods by making many small changes.  Farmers in one area would build a part of a levy to protect a few homes and fields, while farmers in another area would build channels for the water to run through to prevent flooding.  They worked hard to perfect their ways of moving water.  They even founded a small school where people could take classes on the best way to channel water, led by their very own Expert Teacher of Flood Prevention, Mr. Grounds.

    On the west side of the river, people responded to the annual floods by seeking out the reasons for the floods, finding that there are three smaller mountain rivers that combine to create the seasonal floods.  They decided to build a dam on one of those rivers to control the floods.  They built a number of small dams and worked to improve their methods and techniques.  They even appointed a Chief Water Engineer, Ms. Heights, who mentored and supervised the building of dams.

    As these methods became more sophisticated, the east siders and the west siders would both come to the town council asking for people, tools, raw materials, and money to address the flooding problem.  At first, the town council had no problem providing resources to both sides of the river.  After all, both had good ideas and both had proven that their ideas could work.  However, neither had addressed the overall problem.  The river still flooded every year, and although the smaller dams on the upper rivers had reduced some of the threat, and although the levies and water channels allowed some of the water to flow off fairly well, the floods were still coming along every year or so, and wiping out homes and farms. 

    One year, the river went wild.  There was more water than anyone had ever seen before.  Upstream, most of the small dams held, but one of the dams simply overflowed and eventually burst, sending cascades of water downstream.  Downstream, most of the levies failed, and the waterworks were unable to keep up.  A hundred farms were destroyed, and three of the townspeople lost their lives.  One of the roads used by the traders was washed out and crops in storage were ruined.  The townspeople became angry and upset.

    The town council called a special meeting, and both the chief engineer Ms. Heights, as well as the expert teacher Mr. Grounds, were roundly criticized.  Both had been telling their neighbors for years of their vision. Both had been saying “our valley will not flood, someday, if we do things my way.”  Both seemed wrong!  There was confusing and dismay.  Some east siders wanted to try building dams, while some west siders wanted to build levies and waterworks.  The arguing went well into the night.

    The mayor has stayed out of the fight for the first few hours, listening and watching as both sides made their case.  Finally, he stood up and started to speak.

    “People of Busit, I ask for a moment of your attention.  I’d like to propose a solution.”

    The arguing died down as the room turned to focus on the mayor. 

    “Some of you trust Mr. Grounds.  After all, he is knowledgeable and kind, and has taught you how to protect your lands from the water.  Others trust Ms. Heights, who has proven that her methods can work even in extreme situations like we faced this year.  I trust neither of them.”

    A shocked silence fell.  What does he mean by that?

    “I don’t want one person or the other to win.  I want the entire town to win.  We have to protect our farms and our way of life, and we have to do it together.  We have to know the course we will take and we have to take it as a town.  Both Mr. Grounds and Ms. Heights have failed us.  They have spent a lot of time trying to convince us, but no time at all trying to convince each other.   We are all responsible for this.  We all participated.  This year, we lost John and Mark and Mary to the floods.  How many more must die because we cannot agree?” 

    The last question cut through the room.  Farmers and townsfolk, east siders and west siders, looked at one another, eyes darting around the room.  Heads nodded and bowed in recognition.  We did this.

    “Tonight we will go home.  Next week, we will return here.  At that time, Mr. Grounds and Ms. Heights will present their solution.”  He looked over at the two leaders and fixed his eyes on each.  “Next week, they will present a single solution that both will dedicated themselves to supporting.  Both will work for that single solution, with all their might.  Both will agree.  If they cannot agree, both must leave Busit.  If they do not create one solution, then they are both wrong, and we cannot afford for them to remain.”

    Both Mr. Grounds and Ms. Heights were caught off guard.  They both started to argue, but the mayor turned to the city council and shouted “all in favor, say aye.”  The council responded in loud unison, drowning out the commotion with a resounding “AYE!”  The arguing stopped.  The consequences were clear and unequivocal.  If they agreed with one another, they got to stay.  If they disagreed, both would be kicked out of town. 

    “Meeting adjourned.”  Concluded the mayor.  The townspeople filed out of the room, speaking quietly among themselves.  Who would win?  What would the answer be? 

    The next week was filled with rumor.  Everyone had an opinion.  Some liked Mr. Grounds down-to-earth approach and thought he’d win.  Others like Ms. Heights skill and intelligence and thought that she’d win.  Others thought that they’d never agree and that both would be kicked out of town. 

    That next week, the town hall was filled.  People flowed out into the courtyard.  Inside the hot stuffy room, the mayor called the council to order and reminded everyone why they were there, and what the consequences would be.  Then he turned to Mr. Grounds and Ms. Heights to stand up and explain their solution.  A hush fell across the room as both of them walked together to the podium.

    Mr. Grounds started out in an unexpected manner, by complimenting Ms. Heights for her excellent ability to construct dams.  Ms. Heights then chimed with, complimenting Mr. Grounds for building a community of practice and real expertise in the construction of local levies and waterworks. 

    Mr. Grounds then continued, “We would like to propose a new way.  We will build a series of waterworks in the upper part of valley to create a great marsh.  The marsh will foster wildlife and at the same time, will provide a mechanism to control the floods.” 

    He turned to Ms. Heights who continued.  “Building a great marsh will require large scale planning skills.  The dam building team that I’ve developed will need to use all their planning skills to survey the land, map out the flood plain, and engineer waterworks of a size and scale that we’ve never seen before.”

    Mr. Grounds took his cue.  “The construction of a marsh will require all the skills and talent of the farmers who have attended my school all these years.  We will need your thinking, your assistance, and your support to make this happen.”

    The room sat is silence for the next hour as both of these leaders took turns explaining the tradeoffs that the town would have to make.  Considerable resources would need to be spent, and some farms would have to relocate.  People from both the east side and west sides of the river would have to contribute, cooperate, and assist.  Mr. Grounds school would change focus, to educate the people who would build and maintain the marsh, while Ms. Heights dam-building team would be the first folks to attend.  One of the dam builders would stay behind and to educate more engineers.

    Once the outlines of a solution were laid out, the council was asked to vote.  Some members of the audience sounded out their objections, wanting to delay the vote, but the Mayor asked for a vote anyway.  The council was divided, but the majority supported the new plan, with council members from both the east side and west side joining together to support it.

    For many years, the people of Busit worked together, building a great man-made marsh to contain the waters.  After just two years, most of the flooding was under control.  To guard against major storms, three more small dams were built in the mountains, and a new set of uniform levies were built to defend the lowest lying areas in the town. 

    The town was unified and peace returned to Busit.  Soon the town was more prosperous than ever before.  The floods were controlled and without their annual disruption, the town grew healthy and strong.

    -------------------------------------

    This parable of conflict and resolution will be referenced in later posts. 

  • Inside Architecture

    Are we documenting the wrong things?

    • 2 Comments

    James McGovern blogged recently about his dislike of documentation as part of software development.  While I disagree with his style and penchant for hyperbole, McGovern asks some good questions.  Do we create documentation “because we should” or do we create documentation in situations where it has proven useful, where people read the documentation, and where actions are taken based on that documentation?

    McGovern concludes his post with the following question:

    “I am of the belief that documentation should explain decisions taken and not taken, Why an approach, architecture or algorithm was selected and what else was considered and rejected. Bet the developer in most shops wouldn't have documented this since he/she may not even have visibility into the choices made along the way. So, when you are asking for documentation, what are you really asking for[?]”

    I agree with both his statement of value (Documentation should explain decisions) and his concern about having developers do the work (he/she may not even have visibility).

    But let’s take that one step further.  If documentation is valuable in that situation, and if developers can’t meet that need… then who can?

    In my experience, the architect is one key person who has visibility to the choices made along the way.  She may be a system architect (for technical decisions), a business architect (for localized business decisions), or an enterprise architect (for cross-organizational business and technical decisions).  When properly supported, an architect is one of the few people charged with documenting alternative designs, getting discussion and consensus, and building a solution that everyone can buy in to. 

    But what would that documentation look like? 

    This architectural document is NOT a design spec.  It is NOT a requirements document.  It is NOT an API. 

    Useful documentation from an architect needs to focus on decisions.  From those decisions, come rules

    In my current practice, I have developed a new document type called a Technical Policy and Advice Document or TPAD.  This document is focused on a single key technical decision (with all motivations, scope, exceptions, and signatories).  These are “technical policies” in the sense that they are decisions made and ratified across a group of people.  The second half of the document is “advice” which describes a design useful for implementing the technical policy.  The design is documented using architectural models and the allocation of responsibilities.  The document is short (less than 10 pages) and specific.  The document includes both a business decision and a technical approach for executing it. 

    I’ve had a lot of “push back” against bringing together these two elements in a single document.   There is a downside in that signatories can’t agree to “part” of the document.  Different people have to agree to both parts.  Putting them together in a single document make for a more difficult decision-making process.   On the other hand, Microsoft is a company where the opinion of a technologist is taken very seriously.  Business decisions are influenced by technologists, and if you go to one and not the other, decisions are simply not made.

    For documentation to be useful, it has to be used.  This documentation is useful because projects can be based on it, and technologists throughout the company can see the high-level business people who have made a decision.  If they don’t like the decision, they can speak to those business leaders.  This visibility helps prevent passive-aggressive business behavior. 

    Project managers and Developers can read that documentation and take actions based on it.  It is architectural at the business level as well as the technical level.  And, hopefully, McGovern will like this aspect: developers don’t write it. 

  • Inside Architecture

    Enterprise Architects Are The Gears, Not The Grease

    • 2 Comments

    I’ve often heard “soft” metaphors used when discussing Enterprise Architects.  Some compare EA to the grease in a machine… necessary for the machine to run but we don’t provide the energy for progress so much as we reduce the friction.  Others use a “sticky” metaphor, saying that EA is the glue that connects strategy to execution.  Those metaphors are flawed because, in each of them, I can easily imagine a system where there is no grease or glue and the system works just fine.

    I am involved in an effort to clearly define the role of an Enterprise Architect in my particular space.  The way that I’m working on this clarification, I cannot say that EA is something mushy.  EA is part of the machine itself.  To use the “engine” metaphor, an Enterprise Architect is a gear, not grease.  We work at the same speed as the engine, churning through data, decisions, and governance at the rate demanded by the business. 

    I do understand that small organizations may not need an EA.  That is because the problems addressed by an EA are not so easily buried under politics and personality in a small organization.  The CEO can see them and can address them.  In larger organizations, you get shared services, competing priorities, and, in most cases, political games designed to swing decisions with partial data or one-sided decision criteria.  That is where EA really shines. 

    In these environments, EA is not a ‘soft’ role. To be an effective EA, you have to know when to stand your ground and defend the requirements of the enterprise.   You can force conversations to be held that wouldn’t otherwise occur, and decisions to be made that some would rather avoid making, using data that is sometimes difficult to collect in a fair and impartial manner.  That is not a “grease the wheels” function.

  • Inside Architecture

    Business Architecture Apprentice Training Model

    • 2 Comments

    There is no question that businesses need Business Architects.  There is no question that business architecture in an important set of activities.  The question is, really, where do we get them?

    I’ve seen no lack of interest in this field.  If anything, there is a steady supply of willing folks in IT who would love to fill the role of Business Architect and perform those services, if they had the position, training, and tools to pull it off.  These people are smart and capable, and most of them can do the work if given the time and training (not all, of course.  This is not work that everyone can do).

    Recently, Sy Blank, a friend of mine, asked for my opinion: why a Solution Manager (IT Program Manager) cannot simply be promoted to a Business Architect, and learn on the job… Here was my response.  (Please note: In editing my response for the blog , I inserted the term “program director” to refer to the people who manage the Solution Managers.  My assumption is that a person who is “promoted” in this way would continue to work for their existing manager).

    Hi Sy,

    Thanks for asking.  You asked why not just promote Solution Managers (SMs) into the position of Business Architect (BA) and let them learn?

    I can assure you that the transition from SM to BA is quite difficult.

    1. There are new skills involved.  New tools.  New concepts.
    2. Being effective at business architecture requires a  paradigm shift around the role of IT and the role of SD. 
    3. Most program directors have no experience with the role of Business Architect, and may have a difficult time supporting their work.
    4. Existing relationships with customers can actually GET IN THE WAY because customers will look at an SM, who they’ve worked with in the past, and assume that they should be handling project and program-level issues.  That gets in the way of effective BA efforts.
    5. SM training programs can actually cause role confusion.  

    If we were to follow the suggested approach, the training model would look like this:

    1. New BA is anointed by a program director without substantial support.
    2. New BA is assigned to BA team.  If they are lucky, they take a one-day course within four months of starting.
    3. New BA is held accountable to doing work that they do not understand, that most of the “customers” don’t know what to do with, and that their managers cannot discern the quality, difficulty, or effectiveness of.

    The odds of success are so low that we would be sabotaging the entire effort.  Nearly every new BA that goes through that model will fail.  The only ones that will succeed have found a way to supplement with mentoring from an existing BA or someone who has performed BA duties in the past. 

    IMHO, an effective training model for Business Architecture would look like this:

    1. We have a clear idea of what it means to be a proven effective BA and we have reviewed every BA according to that rubric.  All are aware of where they stand.
    2. Proven effective BA team members are given the title of “Red Belt” Business Architects.
    3. A new BA is specifically hired for the skills of Business Architecture: business acumen, visual thinking, relationship skills, political awareness, personal awareness, trust-building instincts, sales skills, data collection and refinement, business modeling, business model analysis, negotiation, etc.  (just off the top of my head).
    4. A new BA undergoes two weeks of intensive training.  After which they are a “Green Belt” Business Architect.
    5. Each Green Belt BA is assigned to work under a Red Belt BA in the Red-belt BA’s own governance body as a direct report.  (No dotted lines.  No extended oversight.  Direct report.  Period.)
    6. A green belt has to meet the bar for “proven effective” to gain their own Red Belt. 

     

    Note that I did not indicate what would be the criteria for going from Red Belt to Black Belt… I would answer that by saying that it is more than simple technical skill.  A BA would have to prove himself to be measurably effective in at least three (my number) of Red-Belt-Level BA projects before he or she can call himself a Black Belt.  Ultimately, the measure of whether an engagement was “effective” would come from an existing Black Belt, but let’s not get ahead of ourselves.

    Assuming it takes six months of intensive training to “make” a Solution Manager into a Business Architect, and assuming we have about five folks who could qualify as a Red Belt, then we can effectively go from five to twenty Business Architects in a year without hiring outside the company.  Not a very fast clip.

    This begs another question.  Before you set out on a plan to train up a long list of business architects, ask yourself How Many Business Architects Do We Need?

    I hope that I’ve provided a clear and useful opinion.

    --- Nick

  • Inside Architecture

    How many business architects do you need?

    • 0 Comments

    This is an interesting question, and it depends on a lot of different kinds of answers.  The business architecture team here in Microsoft IT has developed a set of services that they will offer to various customers, both within IT and in the business.  There is also a mapping showing which people, within the BA team, are qualified to perform each of those different services.

    Therefore, to answer the question, you have to understand the demand for those services!  How many people want to “buy” service 1?  How long does service 1 take to perform?  How many resources does it take?  A little bit of math and you can get to a starting estimate of the number of folks you need.  Of course, this is just an estimate.  Some folks will seem interested but will never buy the service.  Others will  buy the service and not understand what it is, creating a situation where success is nearly impossible.

    The worst case scenario is when a manager simply “anoints” someone as a business architect.  That is bad for the manager, bad for the newly minted but totally unsupported architect, and terrible for the “brand” of “business architect.”   By definition, everything that they do will be novice at best, and probably just wrong.  Even when quality output appears, it takes twice as long as it should. 

    And every business stakeholder who meets them will think “this incompetent person is a business architect?”  Just try to get them to buy BA services again.  I dare you.

    A careful Business Architecture growth strategy can be difficult to drive.  If you get folks interested, you may generate a LOT more demand than you have capacity.  If you generate too little demand, your window of opportunity may simply close.  It’s a tough road.

    How many business architects you need depends on so many things, but mostly it depends on your brand.  How well have you managed the brand of “business architecture” by making sure that Business Architecture delivers a high quality service every single time?  Perhaps that is the most important question for the growth of business architecture all up.

Page 1 of 1 (6 items)