/Tag: Project Management

All Effective Enterprise Architects Are Agile

By |2016-09-28T22:43:18+00:00January 15th, 2013|Enterprise Architecture|

I explained to one of my clients recently that there is a perception of animosity between the Enterprise Architecture community and the Agile community.  Both sides make assumptions about the other, often assumptions that are simply unfair.  For example, many in the EA community think of “agile practices” as an opportunity to develop software without any architecture at all, while many in the agile software development community think of architecture as one of the “big design up front” guys who oppose their principles and practices.  Of course, it is not difficult to find people who fit those unfair descriptions, but I’d like to point out how these two viewpoints are similar.

I believe that effective Enterprise Architecture must be approached from an agile standpoint.

First off, what does it mean to be agile?  (more…)

Everything you’ve read about IT Project Failure is wrong

By |2012-12-09T17:52:16+00:00December 9th, 2012|Enterprise Architecture|

I did a scan around the web to figure out what many of the leading thinkers were saying about IT project failure and the root causes.  Numbers varied between 20% and 80% of projects failing to deliver on their business case.  The root cause analysis that follows from these failure numbers spends a lot of time looking at the IT project, but most forget to look at the causes of failure that are outside the project’s control.

In the diagram below, the central blue box represents causes of IT project failure that are inside the control of the IT team.  As you can see, there are many more causes of IT project failure that are OUTSIDE that blue box than inside it.  Yet, countless articles have been written on the factors INSIDE the box.  I think it is time we take a slightly wider lens to the problem!


The factors outside the project are as important, or more important, than the ones inside the box.  I have worked on many projects over the years, and if I look back at the ones that ended up cancelled or scrapped, the reasons were not ones in the blue box.  They were usually ones from the top box: where the project should not have begun in the way that it did.  Let’s look at these six factors:

  1. Lack of accountability for success – Sometimes, in an organization, an interesting situation will arise.  I call this the “can’t lose” scenario.  In this scenario, the CIO will suggest that the business can benefit by doing some particular initiative, and his or her people will set out to find a business sponsor for the initiative.  In this case, the sponsor will reap the benefits of the initiative, not the CIO.  (Let’s say that the CIO has suggested a Business Intelligence initiative, and signs up the Chief Marketing Officer to sponsor it).  If the project succeeds, the sponsor wins.  If the project fails, the CIO (not the sponsor) loses credibility.  After all, it wasn’t the sponsor’s idea.  The CIO dreamed it up, after all.  In fact, the sponsor may not do any real “sponsoring.”  He may sit in an occasional status meeting and check his e-mail while the program manager he assigned from his team answers questions… and keeps him protected from any blowback.  The sponsor in this case is not accountable for success.  No one is.  The odds of this project succeeding are small.  (Note: a good IT Governance system prevents this condition). 
  2. Failure to get buy-in from above – Often, a senior executive will ask his operational leaders to suggest IT projects for the planning cycle.  The executive (let’s say Tina Smith, Vice President of Sales) assumes that the leaders (William, Ashok, and Lee: all three are General Managers) will ask for projects that align to their individual strategic needs.  One of those General Managers, William, decides to create an IT project to implement a SOA service bus.  He wants the bus because he is investing in replacing an application and his IT team tells him that a bus is a good idea.  After all, if everyone in the Sales group uses it, everyone will benefit.  But William doesn’t get Tina Smith’s buy in.  He implements his SOA service bus, but when subsequent IT funding requests come up to move other sales applications over to the bus, his peers Ashok and Lee are not interested.  Their priorities don’t include moving to the bus.  William bought a white elephant.  Because he didn’t get Tina’s buy in, none of his peers will reap the benefits.  Is the SOA bus a failure?  Well… it’s not a success.
  3. Misaligned prioritization – Lee James, General Manager of Sales for the Western region of Contoso owns a sales strategy for the enterprise.  The strategy is to make the sales force more productive by moving the company over to a new CRM system.  The CRM system has out-of-the-box support for a long list of reports, but his team tells him that he shouldn’t use those.  Instead, he should put in a Business Intelligence system in the cloud.  Lee wants to trust his team to pick the right solution.  They tell him that the cost of this system is $4 Million over two years.  The company is moving to a new strategy that de-emphasizes the direct sales force.  Instead, the company will be relying on social networking and direct eRetail to make sales.  To make the new strategy work, there are eight projects totally $8 Million that need funding.  There is a competition for dollars in the IT budget.  Lee goes to bat for his $4 Million commitment.  It’s important because “we are already here, so we have to complete the job.”  This is an example of misaligned priority.  The new BI project can be safely cancelled or scaled WAY back to support a strategy elsewhere, but that other strategy doesn’t belong to Lee.  The one that he owns needs money and he’s going to keep fighting to fund it because his boss, Tina Smith, isn’t aware of the tradeoff.  Lee fights, and Contoso loses.  Which project will fail?  Both of them.
  4. Slow decision making – This one is related to the other problems in that it is often, but not always, caused by a poor governance system or poor prioritization of the effort.  In this scenario, the team implementing the project needs the sponsor to make a decision, often one that requires consultation with his or her peers or counterparts in another part of the company.  The sponsor may be unwilling, unable, or incapable of having a difficult conversation.  On the other hand, they may be indecisive.  Regardless, this situation can cause serious delays in a project.  For example, Ashwin’s application sends EDI-formatted messages to a health insurance provider.  The provider had indicated that new fields are allowed in the messages that are very valuable to Ashwin’s line of business.  However, he has to upgrade his EDI translation software to get the new fields.  The EDI translation software is also used by the Finance group to send banking transactions.  Ashwin knows that the finance group will get a benefit out of the upgrade and wants them to help cover the costs.  This upgrade will add $25,000 to the cost of his project and he’s on a tight budget.  The software team offers to write a small component that will insert the fields into the data stream, but its complicated and fragile. Ashwin cannot decide if he should ask the finance team for funding or if he should upgrade the software.  The project team cannot proceed without a decision. 
  5. Lack of authority to drive change – This one is quite common.  Ashok reports to Tina Smith, VP of Sales for IBuySpy.  He has told her that he wants to take the lead on one of her strategies
    : to consolidate all of the eCommerce systems in the company to a single outsourced vendor.  Tina things that this will reduce costs all around, and Ashok is happy to take on the challenge.  His business analyst does a survey and it turns out that the services and support team offers customers the right to buy replacement parts online.  In addition, the “outside services” team allows customers to buy a service contract on their own area of the website.  The main sales site, of course, uses a high-volume low-cost vendor that Ashok is comfortable with.  Ashok sets up meetings with the owners of the other applications, but they choose not to provide the needed transaction cost information or the cost estimates of changing their internal systems.  His data is light but he strongly suspects that there is a good business case for switching.  Unfortunately, he doesn’t have the data to prove it.  Without data, the Tina won’t take the case to the CEO to require the other teams to jump onboard.  The strategy fails.  Neither Ashok, nor his manager Tina, have the authority to require their peers to adopt a lower cost system.
  6. Lack of influence to rally peers – In many organizations, the prevailing attitude is that the boundary between “centralized” services and “federated” services is intentionally fuzzy.  In these companies, there is no policy that requires a function to be centralized vs. federated.  For example, if a company has ten divisions, three may have their own financial processes, while the other seven share a common finance unit.  The decision to use the central finance unit, or to own a federated unit, can be made and unmade depending on who the leaders of the business are.  (Note: leaders change, and with them, these decisions change as well).  This kind of policy is good for flexibility, but creates both inefficiencies and often, confusion.  This is simply a tradeoff in the design of organizations.  It is neither right nor wrong.  In this environment, any business can create a “centralized” function by convincing more than one business leader to come together to create a shared resource.   The flaw comes when a group wants to create a “centralized” (or simply “shared”) function, but they lack the influence needed to get multiple businesses to join the initiative.  Difficult questions of shared funding can be demotivating, and the political need to create “alliances” can be difficult for junior executives that, in many ways, are competing with one another for the next rung on the career ladder.


Each of these conditions has the potential to kill an IT project.  I would suggest that MANY IF NOT MOST of the failures of IT projects can be traced to one or more of these conditions, but these conditions rarely get counted in the statistics for “Causes of IT Project Failure.”  Why?  Because, in most cases, projects that suffer from these conditions are either never funded, or are reworked so that the political problem is simply avoided.  The project business case does not reflect the problem, so the criteria for failure (doesn’t meet the business case) is never met.  Efforts are made to avoid (but not address) the problem before the business case is written!

This is the world of the Enterprise Architect.  These are the kinds of “failure” that fill the eyes and ears of an Enterprise Architect.  If an EA focuses on only these six causes, he or she will deliver real, tangible, and unique value to their enterprise without ever overlapping the roles and responsibilities of an IT architect, business analyst, or technologist.

Positioning an Enterprise Architect for Success

By |2012-07-09T17:45:28+00:00July 9th, 2012|Enterprise Architecture|

As I found in our Enterprise Architecture team in Microsoft, each time an Enterprise Architect is assigned to a specific area of the business, each one has a unique “engagement” with their stakeholders.  In very large organizations (like mine), there may be many different IT units as well as many different business units, all involved in a particular strategy.   Each situation is different.   This leads to a common problem that can framed with two questions:

  1. So how do you know if your Enterprise Architect is doing a good job?
  2. How do you set the right expectations to position that Enterprise Architect for success?

A Model for Positioning an Architect

We developed a simple grid that helps to position the EA with respect to a specific area of the business.  The two axes of the grid are: Architectural Maturity of the “segment” and Maturity of the Architectural Engagement itself.  Within each cell, we put a description of “what we want the EA to do” if they find themselves in that position.

Note that maturity of the engagement is a measurement of a relationship: specifically the relationship between the “business customer” and the Enterprise Architect.  Architectural maturity of the segment is measured against both the business area and the IT groups that they use (see below).  You need to measure the maturity of BOTH variables in order to understand what an Enterprise Architect will need to do to be effective.


Note that the Architectural Maturity axis has four levels, cryptically described as “Level I” through “Level IV”.  This is a reference to our internal maturity model, which I’m not at liberty to share in detail. 

The broad strokes are:

  • Level  I – architecture is not a trusted and well-understood role in business change or IT programs.  (This includes business, information, solution, and technology architecture).
  • Level II – architecture is used and their processes are defined, but not consistently and not well. 
  • Level III – architecture is performed consistently and is part of governance as well as some portfolio planning activities.  The business stakeholder does not take ownership of driving the funding and execution of the roadmaps developed by the Enterprise Architect.
  • Level IV – architecture is performed consistently and is involved in planning and governance.  The business stakeholders involved in funding and overseeing the business changes themselves are engaged with enterprise architecture, have been key in developing the roadmaps, and follow through with regular updates to the future state models and the roadmaps.  In addition, they decide on which initiatives to use BASED ON the content of the roadmaps. 


Using this model

I’ll provide two scenarios to illustrate how this simple grid is used. 

In Fabrikam, we are Enterprise Architects.  Fabrikam manufactures and distributes consumer electronics.  There are six divisions that manufacture different kinds of products (kitchen appliances, television and radio, automotive, etc). Let’s say that we have 18 Enterprise Architects in our EA team.  Fabrikam’s EA has divided into three working groups, each with six architects.  Maria manages one of these teams, and has six enterprise architects working for her.  Her team focuses on addressing business issues related to supply chain management. 

Maria is performing an annual review for two of her architects.  They are Tomas and Jai. 

Case 1: Tomas

Tomas is working with the kitchen appliance team.  This is the oldest division in Fabrikam, and they have their own IT group that has been stable for many years.  That team has established processes for IT architecture but no business architecture.  Their architectural maturity is Level III.   Tomas just moved over to the kitchen appliance division from the television and radio division.  He is a well established architect with years of experience, but the kitchen appliance team is just beginning to get to know him.  As a result, the maturity of the engagement is “Useful.”  

The intersection of these axes has the following text:

  • Engage in existing review and governance processes
  • Engage stakeholders in cross business decisions
  • Collect current state data

Maria can set expectations with Tomas and with the Kitchen Appliance division.  Tomas will be expected to engage in existing governance and review processes.  He will be expected to work with business stakeholders in the kitchen appliance team as well as other divisions to address shared opportunities, capability overlaps, and strategic prioritization.  He will be expected to collect current state information models, system models, technology models, and business strategies for the EA repository.  He will be measured on his ability to deliver on these expectations.

Case 2: Jai

Jai is working with the automotive division.  This is the newest division in Fabrikam, and they are just beginning to roll out their first set of after-market automotive radios and CD players in the North American market.  Their IT division is small and rather chaotic.  Their architectural maturity is Level I.  Jai has been working with the automotive division for about two years, and has repeatedly earned recognition from their business leaders for his skill and depth of knowledge.  The maturity of the engagement is “Influential".

The intersection of these axes has the following text:

  • Demonstrate EA specific methods and deliverables
  • Drive the scoping, approval, and oversight of an enterprise-relevant project

Maria can set expectations with Jai and with the automotive division.  Jai is expected to demonstrate EA specific methods and deliverables.  The teams know him and trust him.  He can demonstrate how EA can be valuable by simply doing the work and showing how valuable the results are.  Due to his level of influence, he can work with the business to invest in an area of improvement that will benefit the entire enterprise (for example, a project to improve the distribution of finished goods to retailers), and then work with the IT teams and business stakeholders involved to get the project launched and oversee its development.  Jai can be measured on his ability to deliver on these expectations.


In small organizations, Enterprise Architects can be “heros” and just “do what works,” but if you are trying to develop a mature EA program, each architect needs to have specific goals and specific deliverables that they will be expecte
d to deliver.  This kind of model, we found, is useful for helping each architect to position themselves and their role in the organization.

Inserting Architectural Governance into the IT Program Funding Cycle

By |2010-06-15T08:50:52+00:00June 15th, 2010|Enterprise Architecture|

People do what you pay them to do.  That much is clear.  In most businesses, if you pay (reward, incentive) your employees for performing a particular task, then the task will be performed.  Also in most businesses, people are busy, so if you don’t pay them to perform a particular task, it largely won’t be performed.

So in organizations where there is little or no tradition of governance, and where many people openly oppose the notion of having another person or team “telling them what to do,” how do you get people to sign up, show up, and put up?  You pay them.

I’m not talking about bonuses, and I’m not talking about personal rewards.  When dealing with the governance of projects within a business, I’m talking about requiring them to justify hours spent against a budget, and then creating controls that create and distribute the funds for that budget. 

A large number of IT shops use this mechanism for basic governance.

A primer…

Let’s say you have five project teams.  They all want to perform different projects based on what the business wants (or, as is often the case in IT, based on what IT believes that the business needs).  But there is no way that all of those projects can actually be completed in the coming year.  You can use priority to decide what to do, or you can use teams of architects to drill in to the project teams and determine what features will be built, and by whom.  But that doesn’t mean that the decisions made in advance will be followed.  Just because business leaders don’t want that ESB, does that mean that the developers won’t build it?

The rigor needed is to require project managers (and in some organizations, the project team members themselves) to “book” their time against a budget that has been set aside to fund their project.  So team one, that wants to build features A, B, and C, starts with an estimate the costs of that effort.  The architects and planners decide that team one should only build features A and B.  So they budget only enough money to build A and B.  Assuming that people are actually pulled off of projects when the money runs out, then project teams will have a built-in incentive to either deliver what they promise, or inflate their estimates so that the amount requested covers all of the desired scope, regardless of the executive decisions.

Now, in this environment, how do you add architectural governance?  Add architecture to the funding model, of course.

When a project is being considered for funding, take a look at specific attributes of the project.  If it is important, large, risky, or likely to need oversight, then it should follow specific rules for architectural governance.  (The rest of the projects, which will account for a large majority of the budget, do not require architectural governance, and can simply negotiate directly with their business stakeholders on the basis of ROI).

This subset of projects needs special governance, architectural governance.  That means that specific requirements are placed on the project as it is being conceived.  In fact, you may need a two-stage process just to get the project started: stage one to get the information in place to decide whether to do it, and stage two to perform the actual project, with a funding decision taking place in the middle.

The key requirements for deciding if a project should be performed will go far beyond the normal ROI calculation.  Large, risky, or potentially game-changing projects need to have architects fully engaged to help set the scope of the project, decide what enterprise assets will be improved or addressed, and focus in on stability, scalability, security, agility, and performance.  Information has to be collected about the components in other systems that need to be improved, so that careful dependencies can be taken.  Roadmaps need to be lined up because success may depend on many projects producing changes in many systems.

The flexibility that the business will have in “compressing the scope to reduce the budget” will be severely curtailed.  The ROI calculation will not be quite as flexible, as there will be a great deal of cost that the business cannot squeeze out. 

A team of architects needs to oversee this information gathering process, and needs to be present to defend the costs when the business tries to compress the budget or take short-sighted cuts.  The project needs to deliver value frequently, all the way to the customer, in a rhythm that increases confidence in the IT organization to succeed.  Only if all of these criteria are planned in, and carefully described, can the project get through the funding process and begin effort.

All the architectural review in the world can’t begin to provide the value that architectural governance during the funding cycle provides. 

Sometimes, to win the game, you have to be at the right starting line…

It has value… but do you need it?

By |2010-06-09T11:06:00+00:00June 9th, 2010|Enterprise Architecture|

Recently, Chris Potts threw this nugget out on Twitter:


Instead of ‘demand-managing’ to fit an arbitrary IT budget, challenge whether your strategy needs the value an investment is promising

What a terrific comment and one that really hits home with me.  As we look to create “alignment” by showing “traceability” in Enterprise Architecture, the process models and practices that so often show up in frameworks go on and on about “demonstrating that an activity can be traced to a strategy.”  However, there is nearly no talk about what happens next… showing that the value produced by an activity is actually necessary to make the strategy come to life!

A number of years ago, I worked at a financial institution.  They were a large company, and had a fairly relaxed dress code… except my department.  I worked for one of the hundreds of Vice Presidents and his team was required to wear nice suits to work every day.  Now, I have nothing wrong with wearing a suit.  But this was in South Florida, and wearing a lot of clothing has its drawbacks, especially in the afternoon when the sun was high in the sky. 

But I followed the rules and bought suits… many of them.  Now, I could have purchased cheap suits, but my manager had a keen eye for fashion and he would not have been happy to let me make presentations to senior executives if I was not well dressed.  On the other hand, I could have bought really expensive designer suits for $1,000 or more each.  I would have looked good, for sure, but I would not have seen a positive impact on my career.

I went with nice, well tailored suits… that looked good but were not so expensive that I’d be going into debt to buy them.  $400 or so for each one.  My career was stable and my manager was happy.

If I take that metaphor and apply it to IT planning: we often find ourselves with a project that represents a $1,000 suit.  It is expensive, yet delivers moderate value.  So if I already have a closet full of $400 suits, do I buy it?  No.  Now, what if I don’t have a closet full of suits.  I need one… but do I need a $1,000 suit?  No.  I’ll cut the costs down, trimming scope and resources.

In every case, that $1,000 suit was directly traceable to my strategy (“comply with business expectations, and grow my career visibility”), but in both cases, I did not buy it. 

Chris Potts’ observation was excellent and well worth understanding.  Alignment, alone, will not insure that IT delivers value.  It is not just about delivering value.  It is about delivering the right level of value, sufficient to bring the strategy to life, without incurring unnecessary costs. 

Now… to apply this thinking to business intelligence… hmmm… 🙂

How the Program Management Office Views Enterprise Architecture…

By |2010-03-10T12:58:15+00:00March 10th, 2010|Enterprise Architecture|

There’s an interesting analysis available through the PMO Executive Board on “Project Interdependencies.”  In the problem statement, the author correctly observes:

As the volume and size of projects grow, the old problem of managing project and program interdependencies is becoming more acute: three quarters of PMOs consider “managing interdependencies” to be one of their most critical program management challenges.

First statement is cool.

Unfortunately, the next concept is somewhat troubling to me.  According to the author, the solution to this problem is one of process 

“… the ability to track and communicate project interdependencies boils down to two essential managerial disciplines: good risk management and clarity of communication with senior executives.”

In other words, we can track and communicate interdependencies better if improve our ability to manage risk and communicate interdependencies.  Is that argument convincing to you?  Seems pretty circular to me.

Digging a little deeper

Let’s take a look at the “project interdependency problem” for a minute.  If projects had no interdependencies, there would not be a problem.  However, if one project must complete before another one can deliver value, then there is an interdependency. 

This is a problem because we may not know which project is the “critical path” project, so we may not do a good job of accounting for delays or cost overruns in the “source” project that can ripple across many other projects.  In that aspect, understanding the interdependencies is a CRITICAL problem for the Program Management Office. 

But let’s dig a little deeper.  What causes projects to be interdependent upon one another?  According to the same analysis, the factors to consider are:

  1. data,
  2. artifacts or deliverables,
  3. technical functionality,
  4. infrastructure capabilities,
  5. milestones, and
  6. end-user commonality.

Think through the list above.  How many are NOT architectural?  You could say that end-user commonality is not architectural, if you were to exclude business architecture from the discussion, but once you examine the kinds of models developed in an Enterprise Architecture context, 100% of the types of interdependencies chartered in these different projects are visible in, or predicted by, the architecture of the systems.

Improving the advice

I am not saying that a PMO shouldn’t be concerned with Interdependency management.  It is not the job of Enterprise Architecture to track, communicate, and drive the flow of the project portfolio. 

What I am saying is that the advice needs to be extended.    The second sentence above, and the entire presentation to follow, needs to recognize the clear dependency that the PMO takes, or should take, on the Enterprise Architecture team to identify, review, minimize, and prioritize systemic and project interdependencies. 

In other words, the second sentence above would become:

“… the ability to track and communicate project interdependencies boils down to three essential managerial disciplines: timely development and delivery of Enterprise Architecture, good risk management and clarity of communication with senior executives.”

Modeling User Experience Scenarios

By |2009-11-10T19:01:00+00:00November 10th, 2009|Enterprise Architecture|

I’m working on modeling some requirements for a document management system.  I’m a big fan of using models to represent every element, from goals and strategies through to business processes.  From there, I model use cases and requirements and on down to system components that fulfill those requirements.  Just call me a traceability hound.

I find that the effort to develop requirements in this way is, if anything, substantially less than the traditional “text first” method, and I can always output text documents for those times when people need their Word Document.

User Experience Scenarios are not, however, an easy fit with our current modeling languages.  We have models for business processes (which are excellent for illustrating activities in the scope of roles), interaction diagrams (which are excellent for illustrating component lifecycles, timing, and information flow), and activity diagrams (which are excellent for illustrating the activity of a single module).

I am not completely comfortable illustrating a user scenario in any of these three visual languages.   They really capture the wrong information, and fail to illustrate the things I care about.

For a user scenario, I want to know what persona is involved, what motivation that persona has for interacting with my business service, and what information they will have before the scenario starts.  I also want to know what constraints they will expect of the scenario: what is their level of commitment to my business service?  How frequently will they be interacting, and what is their understanding of the underlying information?  While I can annotate one of the UML models above with this information, I cannot truly model this information in the UML diagrams described.

I’m using the following diagramming “language” to describe the connection between people, motivations, scenarios and use cases.  To see this sample full-size diagram, click on it.  The model attempts to show the people involved in creating and using architectural standards. 

Using a UML-derived diagramming language, I can document the scenario (labeled “<<Scenario>>” in the diagram) as a sub-activity diagram.  That activity takes on a sense of reusability, since it can be from the perspective of any involved actor while keeping the actor itself outside the scenario.  This allows a single scenario to apply to different people (Object Oriented Encapsulation, as applied to workflow).

Scenario model

On a different view (a different diagram), I can illustrate each of those scenarios with links to the constraints that I mentioned above (frequency, information objects, level of commitment. etc). 

The advantage of creating a model of this kind is obvious to me, because I’m a modeler.  But for many folks, the benefits may not be clear.  Let’s put it this way: if you change any one object or line, there is the potential for impacting other objects.  With a model of this kind, you can SEE those potential impacts before they happen.  By developing a model, the architect develops clarity of thought, and in doing so, reduces mistakes in the design.

I’m curious if others find this kind of model interesting.

Should some requirements be called out as “architectural” requirements?

By |2009-06-26T10:03:40+00:00June 26th, 2009|Enterprise Architecture|

Some methodologies of software architecture, including EWITA, attempt to describe architectural processes in a manner that is quite separate from the development of software.  Is that valid?

To whit, the first step in the EWITA process is described as “architectural requirements.” Yet, there doesn’t seem to be any definition, on that site, about what criteria we’d use to decide if a requirement is architectural or not.  So if my job is to collect architectural requirements (hmmm…), then I have to ask, “what is an architectural requirement, and how is it different from some other kind of requirement?”

Consider this analogy

A few years ago, when I was considering making an addition to my home, we called an independent architect to come over and discuss details.  We talked about the functionality of the rooms, and where they would be attached to the house, and what changes we’d need to make to the rest of the house.  All of these requirements were shared with the architect, and he was planning to consider them all when creating a solution.

So are requirements architectural if the client tells them to the architect?  I don’t think that is a useful definition.

Are some requirements more inherently architectural than others?  Good question. 

Some requirements came in the form of building codes.  Were those architectural?  Surely, they affect the architecture of the building, but so do requirements about function, size, and even the ease by which we would decorate a room.

In software, the same problem occurs.  Business customers describe their use cases.  Sometimes we talk about using data from other systems. Other times, we talk about speed and performance.  Mostly we talk about functionality.  What the application will do, and how it will make their lives better. 

I don’t differentiate requirements as “architectural” vs. something else.  It is not a distinction that I find useful.  My question, fair reader, is to you: do you have a practice of attributing your software requirements with a note that says “this one is architectural?”  If so, what logic do you use to flip that attribute to “true?” 

I’m just not seeing it.

Make IT appear as simple as possible, but not simpler

By |2009-05-22T20:22:52+00:00May 22nd, 2009|Enterprise Architecture|

Sometimes I hear a complaint from an IT architect who wants to have direct conversations with “the business” or “the customer” but, for some reason (usually bureaucratic), they cannot.  There is a team of analysts or project managers that they are supposed to talk to. 

The original objective of having “layers” of people is to make IT appear simple.  We all agree that business constituents can become confused if they are dealing with a long list of people from IT, each of which have different concerns.  In the worst case scenario, a business user reaches out to an analyst to tell them about a software error, and the ‘problem’ gets handed off from person to person, adding time and confusing the user.

Many companies favor the “Single Point of Contact” approach. For each business unit, there is a single point of contact for all projects.  There may still be one more point of contact for “support” related concerns.  But that is all.  This hides some of the complexity from the business customer, but adds a layer between IT and the customer.


So where does the IT architect fit?  Does it depend on the type of architect?  Does the enterprise architect need to have direct conversations with business stakeholders? 

What about solution or platform architects?  Should they be talking “directly to the business?” 

It would seem obvious that business architects should, but how do business architects relate to business analysts?  There’s still the support side as well.  Does each application have their own support contact?  What happens when one application has the right data, and the next one over has the wrong data… who should the customer call?

So we have a problem.  That much is clear.  How to solve it?

I’d like to consider introducing a concept into the conversation: interdisciplinary teams.

The notion of an interdisciplinary team is not widely used in computing, but there are many examples in science.  Used widely in research, medicine, and public policy, interdisciplinary teams provide a way for specialists in many fields to work together to solve a problem.  Any problem can be addressed from many viewpoints, using an understanding that emerges from the unique combination of talent and responsibilities.

Many of the processes for collecting and describing requirements, including the well-understood “Joint Application Development” or JAD process, incorporate the same basic ideas, but do so in a less structured manner and only for a single “problem” (understanding requirements). 

What I’d like to see done is to use the concept more consistently.  For Information Technology, and for consulting, this is quite doable.  Instead of having a single person represent IT to the business, have a team of people.  They meet the business on a monthly basis, and the concerns of each of the people can be brought to the monthly meeting.  All of this is coordinated by a single “IT Engagement Manager” or “IT Relationship Owner.”  However, unlike the bureaucratic processes we see in some companies, there are a few rules that apply.

The interdisciplinary team will have predefined roles.  The list of roles cannot be reduced by either the IT engagement manager or business stakeholder.  One person can fill more than one role.  However, the IT engagement manager does not assign IT staff to those roles.  That is up to IT leadership to do.

This kind of interdisciplinary structure can allow a more direct flow of information, communication, and shared commitments than is possible with the “single point of contact” model.  At the same time, the business stakeholders don’t get randomized by multiple requests for the same information or by the miscommunication that comes from collecting different information at different times in different contexts to apply to the same problem.

In many ways, using a single point of contact is an attempt to make the relationship, between IT and the business, simple.  It is too simple… to the point of ineffectiveness.  I believe that a broader approach is often a better one.

Why Agile Development Requires Agile Architecture

By |2016-09-28T22:40:35+00:00April 27th, 2009|Enterprise Architecture|

The dark cloud of the economic downturn has produced a silver lining within Microsoft IT: an increased emphasis on Agile development techniques.  This does not mean that MS IT is new to using Agile.  Far from it.  Agile development practices have been used in various IT groups here for nearly a decade.

What is new is the desire to address the basic development and governance processes themselves to remove the “Bias towards Waterfall” that exists in many of them.  That bias can create a situation where someone can choose to be Agile or choose to comply with corporate policy.  That’s a devil’s choice.