/Tag: Standards

Segment Architecture in a Commercial Setting

By |2011-04-25T01:37:00+00:00April 25th, 2011|Enterprise Architecture|

The notion of an Enterprise Architect in a Segment (aka “Segment Architect”) has been fairly well described in for the Federal Enterprise Architecture Framework.  (FSAM reference).  It is not always well understood, and there are a small number of blog posts that disparage the concept.  That said, in a federal context, the politics of enterprise architecture doesn’t seem to get played out across the blogosphere. 

I am getting moderate traction at implementing the notion of segment architecture in a commercial setting, and I’d like to share my experiences with the community.  This post is one of what will likely become a series of posts on the trials and tribulations of implementing commercial segment architecture.

Preface: FSAM without the bureaucracy

First, a caveat and caution to those folks who are intimately familiar with the implementation of the Federal Government version: while I took a great deal of inspiration from FSAM, I cannot pretend that I have made any real effort to implement the FSAM in my organization.  As an outsider to Federal IT governance, I am looking through a very narrow lens.  The OMB is the overseer of overseers.  They rely on reports submitted by the agencies themselves.  Each agency is a large organization with billions of dollars of funding. In order to support the multiple tiers of oversight demanded by Congress, huge amounts of information must be put into standardized reports and fed upstream for oversight.  This emphasis on standardization and documentation is simply overkill in a commercial setting, where governance is a matter of judgment, and not a campaign pledge or a debate on CSPAN. 

I appreciate the difficulty of the OMB’s job.  I’m glad I don’t have to do it.  In that vein, I started my implementation of segment architecture by tossing out the extraordinary reliance on reports.  I stuck to the goals and concepts of segment architecture.  And that’s where I’d like to start in this post: what problem does segment architecture solve?

The ivory tower problem

The first step in understanding a problem from an architectural standpoint is to explain the problem as a set of interacting responsibilities.  For folks of the BPM bent, this can mean looking at a series of high level business processes.  For folks of a more architectural nature, this is often thought of as a set of interacting capabilities, each of which produces, consumes, or manages information as part of a larger system dedicated to a goal.  These architectural models are extremely useful, because they help to create a mechanism for understanding the problem space and for creating clear solutions.

However, reference models and taxonomies are not solutions.  No one can implement a reference model.  These “thinking tools” are inputs for specially trained individuals, and cannot be used by business people.   Reference models are architecture, but they are architecture for architects.  They are the patterns that architects use, not the blueprints that builders use.


On the other side, there are problem solvers.  Traditionally, in both business and government, an empowered individual will decide that “my organization will go after this goal” and they will direct their team to get to work.  The team may have to modify their existing processes or change their existing systems, and the goal is quickly broken down into a gap analysis, a proposed solution, and an implementation program.  The program will trigger and manage a series of projects and the results will be measured and reported. 

These activities are well understood and problem solvers have been promoted into management on the basis of doing these activities well.  As a result, there is great understanding for them, and support of them.  This culture does not care about reference models, taxonomies, or assessments.  This culture is well populated, and is seen as either the solution or the problem (depending on whether they are successful or not).  This culture of problem solving often outnumbers the architects (100 to 1) and they are slow to change. 

To the problem solvers, enterprise architects live in an ivory tower. They create models that are correct, but useless.  They do work that is visible, yet not necessary.  They spend time and money without solving any real problems.  To the problem solvers, a reference model is pretty useless.  A reference model plus $5 will get you a cup of coffee. 

Building bridges from both directions

In order for the problem solvers to gain any value at all from the reference models and taxonomies, those artifacts need to be correct and relevant.  Without specific information, they can be pretty, but not pretty useful.  From the solution side, enterprise architects need to gain understanding, relevance, and a tie to the work that actually must be done, the dates it must be delivered in, and the costs that play out across the infrastructure.

For the enterprise architects to have an impact on the problem solvers, their models must also be understood, and there has to be a set of key individuals who use those reference models to get the problem solving moving forward.  There has to be an understanding of how to use the information collected, and how to solve specific enterprise problems.  The problems that an EA is trying to solve are different problems than the ones the business is focused on.  The EA problems are around total cost of ownership, not solution development.  They are around consistency, simplicity, and reliability.  They are not normally focused on specific features, specific constraints, or specific interfaces.

A bridge must be built.  The realization that led to segment architecture is that this bridge cannot be done with training or artifacts or databases… the bridge is constructed of people.  Those people are Segment Architects.

Enterprise, Segment, and Solution Architects

In the problem solving space, you need solution architects.  These are the folks who will build the actual solutions that the business needs from the parts available (existing systems, databases, processes, hosting providers, authorization systems, etc.).  In the enterprise space, you need the enterprise architects.  These are the folks who evolve the future state for the enterprise’s processes, information, roles, and tools.  In the middle, you need the segment architects.  These are the folks who work with the business during the goals, gaps, and solution stage to insure that they enterprise needs and solution components come together. 

The segment architect is responsible for the following:

  • Developing a deep relationship with the business and developing a deep understanding of the problems that need to be solved.
  • Understanding the reference models and providing the needed information to build, evolve, improve, and implement them in the segments.
  • Assessing the state of the processes, information, roles, and systems that are involved in a particular business area to inform the solution efforts
  • Developing the initial “conceptual solutions” needed in order for the programs and projects to get under way, and for the solution architects to have a reasonable and achievable scope to operate within.



The distinct role of Segment Architect

For a while, I’ve had a challenge that is not simple to explain: how is a Segment Architect different from the other roles.  Not simple.  Here’s my attempt for tonight.

First off, let me say this: a Segment Architect is an Enterprise Architect.  He or She is assigned to work within a segment, but could be reasonably assigned to another segment (and in fact, should be periodically reassigned in order to retain their independence).  The segment architect is accountable for all of the responsibilities of an enterprise architect.  He or she must “own” enterprise requirements and insure that they are implemented in line-of-business solutions to the best of his or her ability.  As an EA, they care about where information is created, where it is mastered, and where it is manipulated.  They care about which business units perform specific business processes at a high level, and which governance mechanisms will be used to measure results. 

That said, in the early planning stages, the Segment Architect fills in the (not-yet-funded) role of a solution architect.  He or she will consider all of the requirements, well before they are reasonably understood, using the reference models and taxonomies as analysis tools.  They will develop a conceptual solution that allows the organization to understand what teams will be involved, what systems will be targeted, and what information should be mastered.  Without the segment architect assigned, the business units will perform this architectural activity without any architects in the room, and the result is quite dangerous.  That said, the solution concept developed by the segment architect is a pencil sketch compared to the actual solution that will go live.  It is directionally correct, but the real solution may take on a very different character.

The segment architect does not get the privilege or the honor of actually delivering the solution.  That honor, and that responsibility, falls to the solution architect who will be held accountable for meeting enterprise requirements as well as solving specific business problems.  The solution architect is assigned to the actual project, and has to deliver on it.  The EA does not.

Tell me what you think

I hope that this article provides some of the basics of segment architecture for the EA community, and opens up a channel of dialog about this important and emerging role within the Enterprise Architecture profession.  I am open to questions and concerns, which I may answer in subsequent blog posts.  Please feel free to share your ideas.

One bit of credit that I’d like to give.  Finding an image of a chasm that business people can cross is not easy.  The images if a chasm that I used in this blog post originated from an April 2004 article on the IBM web site called “Bridging the Chasm between Strategy and Execution” by Sydney Fuchs.  The article is quite good and I recommend it, but the context is not quite the same as I used in the image here.  I did not ask for permission before absconding the image, modifying it, and repurposing it.  I hope that Mr. Fuchs will forgive the intrusion.

Drawing Effective Technical Diagrams

By |2010-04-29T09:41:00+00:00April 29th, 2010|Enterprise Architecture|

As architects, we spend a good bit of time trying to get a very complicated set of ideas communicated in a clear, consistent, and understandable manner.  A simple diagram with a clear story can be very compelling.  A poor diagram can actively sink your efforts. 

A great example of a poor diagram appeared on the front page of the New York Times a few days ago.  This horrible diagram attempts to describe the complexity of the US Afghanistan Policy in the war we are fighting there.  The diagram didn’t have a clear message, metaphor, or organizational method that allowed key observations to be drawn from it.  (copied below)

About the only decision that this diagram supports is “simplify this.”  But there is no clear way recommendation on how to do that, the areas that need the focus first, or even the rationale for the complexity that has emerged. 


So what can we do?  We live in a complex space.  We’ve all delivered complex diagrams before.

I got a note from another architect this morning pointing to a masters thesis produced in 2006 by Noah Iliinsky at the University of Washington.  This masters thesis, titled Generation of Complex Diagrams: How to Make Lasagna Instead of Spaghetti , provides a great deal of good information on how to tell if your diagram is any good, and how to develop a better diagram for the audience at hand.

Direct link to PDF: https://digital.lib.washington.edu/xmlui/bitstream/handle/1773/3100/iliinsky_complex_diagrams.pdf?sequence=1

Reference: https://digital.lib.washington.edu/xmlui/handle/1773/3100

It’s a good paper, and worth a look for any architect wanting to learn to improve the kinds of diagrams that they produce, and best guide the decisions that need to be made.

Does IEEE-1471 Define Enterprise Architecture?

By |2009-12-13T14:04:06+00:00December 13th, 2009|Enterprise Architecture|

Michael Poulin recently blogged on EBizQ some of his challenges with applying IEEE-1471 to enterprise architecture.  For those not familiar with IEEE-1471, it is an ISO standard definition of “software architecture” that defines key concepts such as View, Viewpoint, Stakeholder, Model, and Architecture. 

For folks who would like a refresher on 1471, and how it connects to UML notions like element, artifact, and profile, see my prior post on the extended 1471 model that we use in Microsoft.

Using the concepts of Viewpoints and Views, Michael finds challenges in the notion that an Enterprise Architecture can be defined by the various views.  He correctly points out that the contents of the view can only illustrate the particular elements that are actually in the model itself, and if we don’t define the scope of the architectural model, then the views will not contain the necessary information.

Michael’s conclusion is “the viewpoints and views, so loved by the IEEE 1471 standard, do DESCRIBE but NOT DEFINE the architecture and the Enterprise Architecture, in particular.” 

With all due respect, I believe that Michael missed the point.  IEEE-1471 does not define the concrete enterprise architecture, nor the abstract enterprise architectural metamodel.  It defines the concept of architecture itself.  There are a few steps in the middle that need to be understood in order to bring all of these concepts together.  Saying that IEEE-1471 does not define EA is like saying “the concept of a Mammal does not define my cat Fluffy.”

IEEE-1471: a conceptual model for any architecture

First off, I don’t believe that Michael is challenging the core notion of IEEE-1471 itself.  The standard mostly defines terms and a semantic model, so that we can use those terms well.  It does not define how an architecture is developed, when, or who does the work.  It is purely a domain model for architecture.

Applying IEEE-1471 to “Enterprise Architecture” means that we will include, in the architectural model, all of the elements that are important to understanding the concerns of “Enterprise Stakeholders.” 

This is where we must re-apply IEEE-1471 beyond it’s humble application architecture roots.  The standard describes concepts that can be applied to any level of concerns, but only discusses those concepts within the context of software.  It is up to us to discuss those concepts within the context of the enterprise.  In Microsoft, we do exactly that, and we have no problem with using IEEE-1471 to define the notion of Enterprise Architecture.  The key is to use IEEE-1471 in the right context.

The diagram below illustrates the relationship that I will talk about in the rest of this article.


Applying IEEE-1471 to Enterprise Architecture

Applying IEEE-1471 to EA requires that we start with a single question: “Who are the stakeholders for an enterprise and what are their concerns?”  If we start there, we can capture those concerns, and create an “abstract viewpoint” that would be useful for creating the necessary views; views that describe and clarify those concerns. 

This process of “abstract-to-concrete” is useful, because it indicates the elements that we need to include in the architectural model itself.  Once we identify those elements, we know what information we need to collect from the enterprise itself.  We can actually scope our efforts, and justify the efforts to collect specific information, only when we understand the stakeholder’s concerns and the views we want to provide to meet them.

Note that the existing standard set of abstract viewpoints, defined in RM-ODP, does a very poor job of capturing the enterprise stakeholders and their concerns.  It is immature and in dire need of an update.

This is the clarification I would make on top of Michael’s post.  It is not about “defining EA by defining the views” (an approach that he calls “out-in”).  It is about defining the contents of an enterprise architectural model by first understanding the stakeholders of the EA model, and the concerns that they want to see addressed, and then creating an abstract viewpoint that you believe meets those concerns. 

This is not “outside in” or “inside out".  I argue that we should define the scope of your Enterprise Architecture efforts by the outcome you need to produce. 

How does IEEE-1471 relate to an Enterprise Metamodel?

Every model has a metamodel: a description of the elements within the model and how they relate.  A metamodel is, itself, a model, and thus has it’s own metamodel.  This hierarchy of models is well recognized, and the UML folks spend a considerable amount of energy and effort to describe the different levels, all the way back to a root level.  (Leave it to architects to want to understand the nature of any “thing".  It’s philosophy at that point). 

IEEE-1471 is a model that describes how you collect any kind of architecture.  In itself, IEEE-1471 is a metamodel.  Looking at it this way, you can create any model you want, as long as it works for your stakeholders.  It can be a model of an application, a business process, and yes, an enterprise. 

The abstract model, or ideal model, of an enterprise is called the “enterprise metamodel.”  This describes the elements of architecture useful for describing an enterprise.  I published part of an enterprise metamodel last spring in the Architecture Journal.   

Using views to decide what to capture in the EA model

Many medium and large organizations are sufficiently complex that it makes sense to hire an Enterprise Architect.  Any such “complex organization” can be viewed from many different angles.  Your “ideal enterprise architectural model” (or metamodel) can include hundreds of entities, some could contain thousands of rows.  Collecting that data in a consistent manner could take a very long time, but you will never collect all that data

You cannot, and should not, do the “ideal” thing.  You need to do the sensible thing… figure out what concerns your organization has, and which views on the ideal model will meet those concerns, and then collect only the information that you need. You only need to collect a chunk of information if you intend to create a view to meet the concerns of named stakeholders.  Limit your efforts to meeting the needs of specific people, not “abstract notions”  and, just their concerns; nothing more.

Inside Microsoft IT, we have a description of an ideal enterprise architecture metamodel.  It took Microsoft a considerable amount of energy, and money, to create it.  But I have no mysterious delusions that we will EVER populate that ideal model with actual data in every defined entity.  The ideal model is useful, because it helps our EA team to be consistent, growing our understanding in consistent ways, so that the data collection effort we do at one time supports the reports we need later.  But the ideal model does not define our work.  The concerns of the stakeholders define our work.

Closing Advice

My advice is this: don’t define the conceptual Enterprise Architecture as a set of views, but do define the concrete EA model as a set of views on an ideal metamodel… because those views have a purpose.  Know the purpose: to meet the concerns of EA stakeholders.  Those views are useful for selecting the entities you need to have, and the data you therefore need to collect.

Once you collect the data, you can produce the views that the stakeholders need, and answer the questions that the stakeholders need answered. 

That is the job of Enterprise Architecture, as expressed using the concepts of IEEE-1471. 

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.

How to Develop a Governance Program (that doesn’t suck the life out of your organization)

By |2009-11-06T18:00:10+00:00November 6th, 2009|Enterprise Architecture|

Enterprise Architecture has a role to play in both developing a vision of the future, and in providing governance and oversight to make sure that the organization can measure its progress towards that future.

The governance part is tricky.  Architectural Governance is part of a larger fabric of governance that needs to exist throughout the organization, not just in IT but also in the business groups themselves.  This means that governance has two masters.  Governance has to align to business value, on one hand, and “measures of compliance” on the other. 

For enterprise architecture, the business value lies on the proposition that systems designed with better architecture will be more flexible, maintainable, and reliable than systems that are not.  Measures of compliance, on the other hand, can include things like “numbers of projects reviewed” or “evaluated quality of architecture is trending upward.”

In my opinion, governance is about motivating people to do the right thing.  All compliance programs are really all about helping a person or team to do the right thing.  There are may ways to that goal.

Of course, it’s a challenge, in any society or organization, to define what it means to “do the right thing.”  I’ve noticed, as I conduct the architecture review program here in Microsoft IT, that there is a spectrum of governance.  Different people in the organization tend to fall somewhere along this spectrum.  Some folks want to “educate and encourage” good behavior, while others want to “monitor and inform” management about bad behavior. 


The reason that I point out this obvious fact is that your Enterprise Architecture governance program will have many components.  One component may surround innovation, and another may surround process improvement.  In my organization, we have a governance process around architectural standards and review

Each component will have an owner.  The owner is the person who is accountable for insuring that a particular behavior (do the right thing) is happening.  For architectural review in Microsoft IT, that is the Microsoft IT CTO Barry Briggs.   He also happens to own the measurements for our architectural repository. 

For each component of governance, it is important that you expose the governance owner to this spectrum and get agreement to the question: “Where on the spectrum do we want to be?”  Even better: add the element of time to the conversation.  “Where should we start?” and “Where should we end up?”

By getting your compliance owner to declare, specifically, where your compliance program needs to be on this spectrum, you are able to do many things:

  1. Everyone, including the compliance owner, knows and understands the posture that the compliance team needs to take.  Other folks may want to interject their own opinion about where, in the spectrum, compliance should land.  If the compliance program team members have a clear direction, then communication is clear, processes can be correctly designed, and expectations can be correctly set. 
  2. The compliance owners’ direct manager (often an executive) can have some idea about where the compliance program is going and why it is going there.  In some cases, this means that the executive can take responsibility for the level of risk they are accepting.
  3. Processes won’t get out of line with the intended behavior.  I’ve seen examples, from our consulting engagements, where the business wants to encourage a particular behavior, and they asked for compliance processes, only to produce the opposite of the desired effect. 

In one case, one of our partners was working with Microsoft on their SOA program.  Their IT Leadership wanted to improve the use of shared services. They developed a shared service reuse program and a governance model to make sure that everyone used the services.  The governance program was poorly rolled out and executed, and the program lost credibility.

As a result, whenever anyone asked about using those shared services, that person was derided and their idea discarded.  In order to get past compliance, managers created a crafty way to “game the system” in reporting the results.  While the compliance numbers looked good on paper, the actual use of shared services declined overall.  The program that sought to increase the use of shared services caused it to decline instead.

Compliance is part of the game when you are trying to encourage good behavior in an organization.  Making it work is not easy.  The person responsible for insuring that compliance occurs has to have the right level of ownership and accountability. But just as importantly, they need to carefully consider where, on the spectrum of governance their program should be, now and in the future, in order to deliver on business value without encouraging different kinds of  bad behavior.

The Semantic Language of Architecture

By |2009-06-19T12:35:11+00:00June 19th, 2009|Enterprise Architecture|

For most of the last decade, we’ve seen a steady growth in the use of a simple “recommended practice” in the world of software architecture.  Well known by it’s designation, IEEE-1471 is officially titled “Recommended Practice for Architectural Description of Software-Intensive Systems.”

The standard defines words, mostly.  It answers the question: “What is Software Architecture” and does so in a simple and elegant manner using the concepts of model, view, and viewpoint.  It is also written in somewhat vague language, with the meaning of some terms being assumed and others inconsistently applied.  Creating a conceptual model from this document was no simpler than creating a model from a typical business document, even though it should have been. 

Regardless of the relatively minor deficiencies of IEEE-1471, we find it a useful way to describe software architecture and our team in Microsoft IT has fully embraced the language and concepts of this simple and elegant approach.  In addition to embracing 1471, we extended 1471 by linking in key concepts from the UML, as well as other notions like “common viewpoint types,” “architectural description methods,” and modeling languages.

A number of months ago, I created a small poster (designed to be printed in Tabloid size or larger on a color printer) that illustrates the value of this simple language.  Embedded in that poster is a conceptual model that illustrates what these terms mean in relation to one another.  I’m sharing the poster here, for others to benefit from.

My goal is to provide a simple way for all architects to illustrate, share, learn from, and talk about the language of software architecture.  I hope that this poster finds its way into classrooms and team training sessions.  Feel free to use the poster as a way to communicate and share.  I did not author these concepts.  I’m simply trying to explain them.


Note: the diagram uses some of the notational conventions of UML, but not many.  If you understand the concepts of association, composition, and aggregation in the basic class model, you can read this diagram.  The verbs on the lines between concepts are written so that a reader can read the association by following the arrow. 

If you’d like the IEEE-1471 Extended diagram, without the rest of the poster, simply click the image below.

IEEE 1471 - extended

Test yourself: 25 most dangerous security programming errors

By |2009-05-31T15:04:44+00:00May 31st, 2009|Enterprise Architecture|

The SANS institute has published a list of the top 25 most dangerous programming errors.  Not only is this a must-read, but it is critical for architects, developers and testers, of all stripes, to be aware of these programming errors.  Unless and until we have platforms that simply prevent these errors, we can combat these security gaps best through education, careful testing, and responsible project delivery practices.


How familiar are you with these mistakes? 

Would you be able to spot them in code you reviewed? 

Would you be able to prevent them in your own code? 

Towards an Enterprise Business Motivation Model

By |2009-04-22T21:03:00+00:00April 22nd, 2009|Enterprise Architecture|

Today marks the end of a long dry spell.  As of today, I’m back in print with an article in the Architecture Journal called “Towards an Enterprise Business Motivation Model.”


Of interest to Business Architects, Strategists, Business Planners, and Management Consultants, the Enterprise Business Motivation Model (EBMM) is the first published model to consider the needs of the multi-faceted modern business, one where the needs of many divisions, and many business models, have to be considered.   

Finally, a model where the competing strategies of many business units can be captured, displayed, compared, prioritized, and placed on enterprise-wide roadmaps. 

I made some controversial decisions in putting this one together.  I don’t expect that everyone will agree with the choices I made. 

Update from the author

Since publishing the article on MSDN, I have continued to maintain the actual metamodel for the EBMM on it’s own website (http://motivationmodel.com).  If you would like to know more about the EBMM, please visit that site to discover the core elements of the model, and the methods that I used to create it.  You can download a PDF of the model or a model file from Sparx Enterprise Architect that will allow you to navigate it easily.  Also on the EBMM site is a complete html sub-site created by the Sparx tool allowing you to navigate through the model, visit connections, and examine the definitions for each of the terms.

Reducing IT overhead by managing the list of IT standards

By |2009-04-22T12:19:46+00:00April 22nd, 2009|Enterprise Architecture|

In tough economic times, we tend to look for ways to cut costs and reduce overhead, so that we can “do more with less.”  In our team, we’ve stumbled upon one such way that I’d like to share.

One of the responsibilities that tend to fall to Enterprise Architecture, in many organizations, is to be the “keeper of the standards.”  As many readers of my blog know, Microsoft IT was reorganized a couple of years ago to merge the management of 13 different IT units into one cohesive organization.  We are still working through that process, with one result being the recent addition of the “keeper of the standards” role to the EA team.

Previously, EA could create standards, as could other teams.  The project teams themselves would follow what they could.  Some were consistently enforced (like privacy and security). Others were hit-and-miss.  A developer in one IT division may have substantially different standards from a developer in another division.  

Not long ago, our CIO sent our EA team out on a rather unique discovery mission: catalog all the standards that exist in any part of IT, and bring them under one framework so that we can reduce the overlap between various standards and create a consistent and defensible set that most everyone can follow.  It turned out to be tougher than it sounds.

Across various IT units, we flushed out thousands of documents that purported to espouse one standard or another. 

And here is where the cost savings opportunity appears.  The processes surrounding the application of IT standards were all over the map.  Some teams performed consistent code reviews, but only reviewed a few standards.  Others had a long laundry list, but many of their developers were not even aware of them.  Many departments wrote standards that they wanted other departments to follow, often with complicated results.  It was a real mess.

To address the problem, we’ve created a framework for simplifying these standards and a v-team to make decisions.  The CIO is driving IT managers to reduce overlap, clarify the objective of each standard, and prioritize on the ones that deliver the most value. 

Once this is process is complete, I expect we will have a much simpler and more consistent view of the standards that various IT stakeholders will need to follow.  In addition, we will have a simplified process for getting standards approved and visible, allowing the truly beneficial standards to take hold more quickly.

In later blogs, I’ll discuss the costs, and benefits, of standards.  For now, I wanted to share this business opportunity with architects in other EA groups.  Manage your standards, and you can cut costs and raise quality in a consistent manner.

Is it time to create an MBA in Business Architecture?

By |2009-03-05T13:40:11+00:00March 5th, 2009|Enterprise Architecture|

Assuming that “Architecture” can be generically defined as “the art and science of designing or constructing something” (adapted from here and here), then what exactly is Business Architecture?

Extending the generalized definition above, a Business Architect should be “someone concerned with the art and science of designing and constructing a business.”  Note the verb: constructing.  A business architect needs to be able to construct a business… from parts.

Reality check: How many people, with the title of business architect, are responsible for constructing a business? 

Most present business architects are technologists, concerned primarily with the alignment of IT projects to business strategies.  They may be planners or solution owners or process owners… but most work in IT departments of large organizations, often directly with the Enterprise Architecture function.

But if we take the view that a Business Architect is responsible for designing a business, or constructing it from constituent parts, then who should have the title of Business Architect?  Should it be an IT person… or should it be a business person?

I do not believe that Business Architecture is a technical function. 

In fact, I don’t believe that IT people do a good job, at all, of describing the architecture of a business, much less making design decisions about the structure, roles, responsibilities, and coordinated artifacts that make up Business Architecture.

But if it is a business skill, what do we get by applying the architectural approach?  We know what it means to be a business person.  What does it mean to be a business architect?

Operating as a business architect requires rigorous engineering skills, an understanding of patterns, and the ability to convey complex ideas through images.  He or she must use a rigorous methodology and clear visual language for creating rich diagrams that depict the business from different perspectives.  To build out the science, we need to create a comprehensive set of cost, flexibility, durability, and agility methods associated with producing viable designs.  Using visual models, business architects can review each other’s efforts, evaluate compliance, test for quality, and to produce detailed design that form the basis of activities.

In effect, if the impact of Business Architecture is to be fully realized, I believe that Business Architecture should become a rigorous and well defined science that is taught to people in Business Schools around the world.  Every MBA would be exposed to business architecture, and some graduates would focus on the profession.

I’m interested in seeing the development of an MBA program in Business Architecture.

Does such a thing already exist?  If you know, please share…

MBA in Business Architecture