Inside Architecture

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

June, 2008

Posts
  • Inside Architecture

    New eyes on an old favorite

    • 0 Comments

    A couple of years ago, Phillippe Krutchen 'reinterpreted' the Tao Te Ching of Lao-Tsu for Software Architects (link).  I saw it again recently and I have some new appreciation for the things I saw there. 

    I most enjoyed this bit.  (Note that the number is a reference to the original Tao tablet that PK used when creating his interpretation.)  It strongly supports the concept that I most believe in: Adoption is the Most Important Attribute of an Architect.

    The architect is content
    to serve as an example
    and not to impose his will.
    He is pointed, but doesn't pierce.
    Straightforward, but supple.
    Radiant, but easy on the eyes. (58)

    If you want to be a great leader,
    stop trying to control.
    Let go of fixed plans and concepts and
    the team will govern itself.
    The more prohibitions you have,
    the less disciplined the team will be.
    The more coercion you exert,
    the less secure the team will be.
    The more external help you call,
    the less self-reliant the team will be. (57)

  • Inside Architecture

    Blame the Computer: A Business Process Modeling Anti-pattern

    • 13 Comments

    Whenever you model a business process, it is inevitable that, sooner or later, you will come to an activity that is entirely automated.  As time goes on, more and more of the activities slip quietly into the technology.  However, I'm noticing a troubling practice in how these automated activities appear on some business process models.  I'd like to weigh in on what I see as an anti-pattern in the process design space.  I'll use a scenario to illustrate.

    Scenario

    In 1975, when Fabrikam started selling specialized parts, each special order was hand-checked.  The order was compared with the pricing agreement that the customer signed, and a special price, based on their agreement, was calculated.  Gradually, as time went on, this activity ('calculate special order price') was automated.

    Here is an image of the process as it stood in 1975 (click image to enlarge):

    Manual Process Example

    Back in those days, Fabrikam used filing cabinets, so the purchase order was added to a manilla folder in a file cabinet.  The folder had the words "Outstanding orders" on it.  It was, therefore, the "Outstanding Orders" file. 

    Fast forward to today.  Fabrikam enters their orders into an order management system.  (in fact, a large number of orders are entered directly by the customers themselves, using the web, but that flow is not illustrated here... this is just for people who insist on mailing in the purchase orders).

    One of the key activities is now completely automated. 

    The problem

    I have seen two different ways to model the notion of an 'automated activity.'  I believe that one of them is better than the other.  Here are the two alternatives.

    Alternative one: systems get their own process activities... (once again, click the image to enlarge).

    Automated Process Example1

    Alternative two: the automated activity stays where it is, and a system FEATURE or system REQUIREMENT is placed in a container that represents the technology.

    Automated Process Example2

    So which one is better?  Which one should we aim for? 

    Who is responsible?

    The goal of a model is to communicate.  Let's start there, and let's look at the language we are communicating with: Business Process Modeling Notation.

    In BPMN, we have swimlanes that illustrate that a team or department or organization are responsible for performing the activities within it.  Summary: Swimlane = Responsibility for Performance.

    This is pretty important.  A swimlane is more than a picture of who "does" what.  It is a picture of who is "responsible" for performing an activity. 

    When we automated the work of 'calculating prices on special orders,' did the responsibility actually change?  It is clear that technology is contributing to the system, but are different people responsible?  If power fails, will the IT department calculate the prices for special orders, or will the Order Accounting Department do it?

    Clearly, it's not IT. 

    And this is why I believe that the second image (Alternative 2) is correct.  I take the view that IT, by automating a process step, does not relieve the original business department of the responsibility for accomplishing that activity.  IT has simply provided a fast and efficient way for the business to do the job.  The business team, in this case, the "Order Accounting Department" remains responsible for performing the activity of "Determine Special Pricing".

    Why should anyone care?

    Is this an argument about pictures?  I don't think so. 

    1. First off, by leaving the activity where it belongs, in the department that is responsible for it, we are clear about the ownership of that activity.  We answer the questions: who defines requirements? Who is on the hook for exception conditions? Who picks up the slack if the system is down for an extended period of time? Who helps create failover and business continuity plans in the event of a natural disaster? 
        
    2. Secondly, by leaving the activity where it belongs, we let the responsibility for process improvement remain with the business.  We do not take away that responsibility by saying "IT handles automated processes, so inefficiencies are no longer a business problem."  That would be borderline insanity. 
        
    3. Lastly, I've come upon a number of cases where, through the long-standing use of automation, the business has lost their institutional memory.  They do not know how to do their business without the computer.  This is a terrible situation, and one that cannot be rectified easily.  By modeling all of the activities involved in a business process, and tying each activity to a feature, we help document what is actually going on.  This is critical information if we ever expect to replace the computer system (a near certainty) or if we ever want the business to innovate (necessary for long term survival).

    In conclusion: We (in IT) do a disservice to our business customers by hiding the automated activities in a separate 'system' process swimlane.  Responsibility does NOT shift with automation, nor should it.  That includes the responsibility for knowing, the responsibility for innovating, and the responsibility for handling the process in a crisis. 

    One thing that IT can never, should never, do... take responsibility for running the business.

  • Inside Architecture

    Open Question: Common vocabulary: Blessing or Curse?

    • 9 Comments

    Requirements are an interesting thing.  We cannot assume that we understand the business, and their needs, so we 'elicit requirements.'  And we write them down.  But "the business" is a collection of different people, and in order to be clear, we need to make sure that everyone use the same words in the same way.

    Within the scope of a single project, this is not terribly difficult, but it is very tough to keep a single vocabulary across an entire enterprise.  It can be a substantial effort to create an enterprise-wide conceptual information model, one that illustrates the relationships between key business concepts for an entire enterprise.  (If you don't know what a conceptual information model looks like, here's a pretty good example from the US Department of Veteran's Affairs.)  You have to get a lot of people involved to create an enterprise-wide model.

    The goal is to create a common understanding that bridges across many projects.  This allows planners to create information models, and future state models, and suggest project changes that will bring the enterprise information together... at least in theory.  The goal is simplicity and consistency.

    But how in the world do we achieve that goal?  Software reflects the requirements, and business people create requirements, and business people, as a rule, are not well versed in the intricacies of the common information model.  They are on a different track completely. 

    Business people won't use the "standard" words, and they won't use them in a standard way.  Even if you get a project to create their own information model, how do you insure that it lines up to the "blessed from above" common information model?

    We need to have a way to recognize that "project-level consensus" is going to be different from "enterprise consensus." 

    So we have competing goals:

    • creating a simple information model for the enterprise, and
    • creating a consistent understanding between the people involved in the project. 

    If we don't get the project to align with the common model BEFORE software is built, then we built the wrong software, and we have to spend more money later to fix the problem.  But if we force the business to use "special" language, words that they did not create, then you won't get consensus and clarity.  You risk the project. 

    How much is it worth to you to get alignment on information models?  What processes do you use?  I'd love to hear from folks.

  • Inside Architecture

    The Usefulness of the Use Case?

    • 5 Comments

    I'm a big fan of use cases.  Great for describing how software is used, and puts context around the use of functionality that helps software developers to create solutions that will actually fit into human activities.  On the other hand, are there drawbacks to using use cases for flushing out requirements?

    Use cases are a 'common denominator.'  They are used to elicit requirements from business users, so use cases need to be understandable to a business user.  They are used to create a picture of functionality for software developers, so use cases need to be useful to a developer.  Use Cases sit in the middle as an excellent and understandable "bridge" between these roles.

    However, due to the nature of the 'story' or 'flow' implicit in a use case, there is a type of requirement that may not be well suited to use cases: business rule elicitation. 

    In this discussion, I'm not proposing a "hard and fast" definition of a business rule.  I will say that a business rule is a constraint or enabler against the relationships expressed in the conceptual information model.  I'll go into more detail in another post.  All this is based on the efforts of a co-worker, and I'd like to give him due credit and reasonable accuracy.  An example of a relationship in a conceptual model may be "Customer places Orders", whereby a business rule would constrain or enable that statement. 

    Key concept here: a business rule can be tested, against the system or information in it, at any time.

    Examples of reasonable rules

    • A customer with a credit rating of less than 5.0 has a credit limit applied to their outstanding balance. 
    • A customer with a credit limit may only place orders up to their credit limit before payment is received.

    But what do business rules have to do with use cases?

    Answer: nothing.  That is the problem.

    If we use the use case as the only mechanism for the elicitation of requirements, we run the risk of writing a "business rule" that includes the context of a business process, when the rule itself needs to transcend the process.  In other words, if we are describing a purchase process, we could, mistakenly, associate the business rules with the purchase activity itself.

    An example of "process pollution" would be:

    • when inserting an order, verify that the order does not cause the total outstanding balance to exceed the credit limit for customers with a credit rating of 5.0 or less.

    This does not create a "rule" in the sense of creating a constraint that can be tested, at any time.  It can only be tested when the order is inserted.  But what about orders that are increased?  What if a customer places an order for 10 widgets, and later decides to increase the order to 500 widgets, when the company has no assurance that they can pay for the first 10?  Shouldn't we stop that increase?  With the "polluted" business rule, we might miss it. 

    There is a process, based on published work, that describes how to create clean and useful rules, and I'll see if I can post bits of it in another post.  The point of this post: beware of using the use case as the sole mechanism for eliciting and describing requirements... because you may pollute your business rules with context that the rules do not need.  Remember: the quality of a system is directly proportional to the quality of the requirements that describe it.

     

  • Inside Architecture

    An open question about Enterprise Architecture, the noun

    • 12 Comments

    I frequently discuss EA as a business function, including in my last post.  However, one request that comes up sometimes is the view of Enterprise Architecture as a thing... a noun.  Many papers and some books refer to 'the" enterprise architecture.  But what is this thing, and how would you share it?

    A little context.  Back in high school, I was planning to become a (building) architect.  I was fascinated by the subject and spent two years in vocational training.  I became a fairly good draftsman.  At the same time, I discovered that the community college had a course in programming in BASIC, which I took.  I fell into technology and the rest is history.  But I still think back on the days spent drawing house plans, and I occasionally reflect on the lessons I learned.

    If someone were to ask me to describe the architecture of my house, the best I would be able to do is produce a SET of house plans, not a single image.  There would be elevations and floor plans and detail plans that highlighted plumbing and electrical.  There would be "wall sections" and specifications for fixtures, surfaces, and materials.  All of it, together, is necessary.  Any one view, without the other views, is incomplete.

    Yet, for some key audiences, and in some situations, a single view is necessary.  When you want to get agreement on high level goals, or set a vision for an entire organization, you need one picture.  One image to rally around. 

    House Plan P5362D

    For house plans, I'd produce a rendering (a color perspective drawing).  If someone wants more information, then the elevations (each side, directly) and the floor plans with minimal detail could be produced. 

    House Plan P5362D

    This is plenty for anyone who just wants to compare or understand, but doesn't need to actually construct the house.  This level of detail allows you to review choices.  Add some detail, and this is sufficient for a ballpark estimate.  You'd need a LOT more detail to build it.  (Special thanks to HouseOfTheWeek.com where you can see this house, and buy these and many other house plans).

    By comparison, there is no standard approach for Enterprise Architecture.  Has anyone tried to create a consensus about what is in a single-picture representation of an enterprise architecture?  If so, I'd love to see that attempt.  There has been an attempt at describing the entire set, many attempts in fact.  The Zachman framework stakes the most comprehensive position.  Yet, even then, there is little consensus on what a single view of an enterprise architecture should have in it, and we have a fairly uneven track record for setting standards for any one view, even in something like the Zachman Framework.

    For an all-up view, I believe the requirements are as follows: sufficient detail to allow top-level people to understand the problem and make choices about a solution.  Simply representing information is not sufficient, if it doesn't lead to hard choices.  In other words, it is not sufficient that we present a model that indicates that "water is wet" or that we store customer information in a database.  We must be able to present many different models, and have the business react to what they see, selecting one. 

    If you were to do that... if you were to present a single model that represents your enterprise architecture, what details would you put on it? What detail would you leave off?

    I'd like to hear your opinion.

  • Inside Architecture

    One EA Team, Three EA Functions

    • 17 Comments

    In my opinion, a business function can often be best understood by describing the processes that compose it.  My last post, I attempted to describe the role of an Enterprise Architect, and the ensuing discussion quickly splintered because everyone viewed the function of Enterprise Architecture differently.

    So, for today's entry, I made an attempt at describing the high level processes involved in Enterprise Architecture.  I did not limit my description to the bits that my team is focused on, but rather tried to cover as expansive of a view of EA as I could.  As my sources for this effort, I relied on the TOGAF and various process charts available on the web, as well as my personal experience.

    Not trivial.  There many different descriptions of the Enterprise Architecture function, and different companies clearly implement their view of Enterprise Architecture, as a business function, in different ways.

    In the end, I was able to create a single process diagram (below) that illustrates the business function of Enterprise Architecture, but only by modeling three distinct sub-functions as independently as possible.  In essence, I can explain the business function of EA by explaining these three functions:

    • Enterprise Architecture as Planning and Alignment
    • Enterprise Architecture as New Technology Innovation
    • Enterprise Architecture as Standards, Methods and Best Practices

    There is some elegance to this description.  I can separate the activities of these processes rather nicely.  I can illustrate business value for each one, each creating a case for EA to exist.  I can point to documents and frameworks that assist with each one.

    Function Processes Business Value
    Planning and Alignment
    • Analyze Portfolio of Applications and Processes for gaps and weaknesses (parallel efforts)
    • Build Future State Architectural Models
    • Create Migration Plans
    • Align funding requests to future state
    This function delivers strategic alignment through financial governance.  By creating a vision of the future, and then insuring that funded projects help to build it, EA insures that the right applications are built.
    Innovation
    • Evaluate emerging technology trends
    • Recommend proof-of-concept projects
    • Recommend infrastructure projects
    • Deliver these projects to completion
    This function provides a research and development organization to the CIO, allowing investment in shared infrastructure and new technologies.  Without an innovation organization, IT teams devolve into "order taker" organizations.  This is the only function of EA that potentially provides INPUT to the corporate strategies.
    Standards
    • Learn from project teams about the "things that work"
    • Share discoveries in a consistent manner.
    • Select tools for IT to improve their quality.
    • Conduct architectural reviews to improve software quality and reinforce best practice.
    This function interacts directly with the project-level work, either in the form of standards and Arch Review Boards (ARB), or in the form of direct contributions to the practices of a team.  Best practices are shared and the teams produce higher quality code more frequently.

    I'm attaching an image of a process flow that includes Business Leaders, business groups, process management, development, and the Program Management office.  If you'd like to see it full size, click on it.

    Enterprise Architecture High Level Process

    The three colored lanes (yellow, green, and blue) are all part of Enterprise Architecture.  The white lanes are other stakeholders.  This image displays not only how these processes are interrelated but also how they are independent of one another.

    Conclusion

    The function of Enterprise Architecture can be described by describing three sub-functions.  Any organization can implement all three functions, or a subset of them, and still legitimately claim that they are performing Enterprise Architecture.  (And perhaps it is the fact that there are seven permutations that creates so many discussions that start with "That doesn't look like EA to me!")

    By illustrating the interrelationships between these various process flows, the model I included provides a simplified version of the high level IT funding and delivery lifecycle.  I'd love to hear what you think.  Did I capture all of the things that EA does in your organization?

    [note: updated process model on 6-13-08 to clarify the role of process improvement]
    [note: updated process model on 6-25-08 to make it more readable]
    [note: updated process model on 9-03-08 to include supporting functions]

Page 1 of 1 (6 items)