Inside Architecture

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

November, 2008

Posts
  • Inside Architecture

    Creating a distinction between business services and SOA services

    • 28 Comments

    I'm always a bit dismayed when I hear the following terms mixed up, or combined: SOA service and business service.  In my mind, these things are different.  In one sense, they are related, but indirectly.

    A business service is a function (or capability) of the business that is offered to one or more customers.  Those customers are often  internal, because this scenario is often applied to corporate supporting functions. For example, the accounting business unit may provide "accounts payable" services to every business division of an enterprise.  Those divisions are internal customers.  The business unit is accounting, and the business service is "accounts payable."

    In some cases, the customers of the function may be both internal and external.  Many years ago, the Carlson company took their marketing division and not only made it into a shared function, that their various internal divisions could use,  but that division was able to offer their services to the general market as well.  They provide a list of shared business services used by both internal and external customers.

    The people who use shared business functions are "businesspeople" of all stripes.  They have work to do, and a business service is simply a way to do it.   A shared business service includes responsibilities, and therefore people who are responsible.  It is a kind of "sub-business" that has customers, and processes, and capabilities, and information.  In many companies, IT is run as a shared business service, providing technology services to many areas of the business. 

    A SOA service is a different animal altogether.  Service Oriented Architecture (SOA) is an architectural style.  That means it is a set of software design patterns.  These patterns are united in their support of a basic set of principles.  The people who use SOA are people who write software.  (If you compose an application, even if it is simple to do, you are writing software.)

    The logical data model that encapsulates this concept is below.  This is a very tiny part of the data model derived from our traceability model, which allows us to recognize the interdependencies between business processes, applications, and business units.  At the top of the image you see business services.  SOA services are on the lower right.  (click the image to enlarge)

    A business unit may provide zero or more business services.  Not all of the capabilities required by a business unit may be involved in a business service. 

    SOA provides the ability to share features.  Those features may provide information, or calculations, or data manipulation.  They may also include the limited automation of some elements of a business process.  SOA services are provided by "installed software" (we use the term "application" many times for this entity... a different blog post someday...).

    Business-vs-SOA-Service

    (note: I updated the image about 12 hours after posting this blog, due to an error in the original image -ANM)

    The point of this post is to provide sufficient context to challenge the notion that SOA provides shared business services.  It does not.  SOA provides shared features that many business units call upon.  Those features are required by the business processes within those business units. 

    Note to responders: before you flame me, take the time to try to map your concepts to the diagram above.  You may find that if you look for your concepts, and not your words, that you are simply using different words than I am to refer to the same concepts.  Disagree with me about concepts and I'm interested.  Disagree with me because I don't use a word in the same way that you do, and we will probably not have a very interesting discussion.

  • Inside Architecture

    Software Reflects The Process That Creates It

    • 4 Comments

    Of all the ‘laws of software’ that I subscribe to, this one is one of the most fundamental, and unwavering.  I cannot find an exception to it, and years of experience reinforce it for me.  I can look at a chunk of source code, or an operations manual, or even a build script, and see the effects of the software development process used to create the artifact.

    Process affects architecture.  If you use agile techniques, you will not only get your results in a different amount of time and features will appear in a different sequence than if you used iterative spiral techniques, but the software itself will have a different structure, different patterns, and different interfaces.

    Just making an observation.  Probably not even a controversial one, but one that bears making. 

    Software reflects the process that creates it. 

    Corollary:

    If you want to improve the quality of the software you produce (regardless of how you measure quality), you can change tools, and you can change information, and you can change training, to your heart’s content… but the big effects will come from changing the process.

  • Inside Architecture

    Using the PMO to measure the behavior of the customer

    • 1 Comments

    There are a great many products on the market these days that provide information about a set of projects.  The idea is to let the stakeholders know how well their money is being spent.  Information Technology departments often get criticized for "always asking for money" but never showing value, so Project Management Offices (PMOs) have been adopting these tools at an increasing rate.

    Most tools capture basic statistics, and then let the IT group add whatever project stats that they want. Today, I want to examine those additional statistics: what measures should the project management office be tracking?

    What logic leads to these measurements anyway?  Plenty of reasons.  Here's my take:

    image

    The key to understanding the metrics is to look at the outcome.  We want to improve the success of IT projects.  The measurements are there to encourage the practices that lead to project success.

    Are we measuring the right practices?  What are the practices that lead to project success? 

    We can guess, or we can go find projects that are successful and ask the project leaders what they did.  We can do this for dozens of projects, and find common actions.  We can look for the "critical behaviors" that led to success, and measure them.

    Some of those things are in the typical scorecard. 

    • Insure that the requirements are stable and well described
    • Insure that the direction of the result is chosen, understood, and agreed to by the customer
    • Insure that the project team is making steady progress toward delivering the final solution
    • Insure that emerging risks are recognized and reported as soon as possible.

    But is this enough?  Are these all of the behaviors that account for success?

    If you ask a successful project manager about the things that lead to project success, have you ever heard things like this:

    • "We had a good rapport with the customer.  When we needed something, he went all out to get it for us."
    • "The customer was part of the team.  Her door was always open, and she made decisions quickly."
    • "The customer really backed us up.  If he had a tough call to make, he'd go get the support from other stakeholders."
    • "When we needed to start user testing, our project sponsor organized all the business resources and made sure they ran the tests they committed to."

    The project scorecard is measuring the success of IT team behavior, but not the success of business team behavior, and as a result, the scorecard cannot possibly predict the success or failure of the project. 

    If building a system requires a partnership, then we need to measure the customer's behavior as well.  Assuming that we do, who will look at the numbers that show a customer that is not being responsive?

    Customers are business people.  They have managers too. 

    Think about it.  The project scorecard can be used to demonstrate that the right behaviors are happening on both sides.  After all, if a project fails because the business sponsor was unwilling to buy in to the approach, or wouldn't sign off on the interface design, or because the business users wouldn't participate in the test process, why should the IT team take the rap for missing the dates or overruns in cost?

    Here's another benefit: if your project team resents the PMO, because they seem like the "project police," then adding the customer's behavior to the metrics can get the project team to sign up.  After all, a complete scorecard is a fair scorecard.  If the project team can point to the scorecard to demonstrate that the business sponsor is being lazy or uncooperative, then they are far more likely to support the PMO.

  • Inside Architecture

    The business value of elegant design

    • 4 Comments

    In my last post, I highlighted the design process, suggesting that designers and architects should consider using creativity, in addition to methods and patterns, to build a truly useful system.  In this one, I'd like to talk about the business value of this idea.  What does the business get by adopting good design practices?

    Before I go too far, I'd like to pass along a recommendation for a book on the subject, "Sketching User Experiences: Getting the Design Right and the Right Design" by Bill Buxton (link).  I have been told that this book will eloquently explain what it means to use good design principles and why every business will benefit.  I have not read the book (yet), so my opinions are unfiltered.  I speak from personal experience of 28 years in the software business, including my focus on the field of "human-computer interaction" (HCI) while attending university and years of passion around creating simple, effective, easy to use systems. 

    I'm also taking a page from a friend and trusted colleague, Peter Moon, who has been sharing his passion for design with me over the course of the past year.  He inspired me to write these posts.  Thank you, Peter.

    Cycles of innovation

    First off, I'd like to clarify what I mean by "using wild creativity."  The process of design, IMHO, is a creative one, but not a crazy one, and we are not seeking 'perfection.'  You can use creativity without blowing the budget or going into 'analysis paralysis.'  First thing is to understand the process itself, and then to understand when, and how, to apply it. 

    When I'm talking about using creativity, I'm talking about a creative process, the result of which is to expand the number of design choices available.  You take a problem and brainstorm out different possibilities in what I call an "expansion cycle."  That gives you many choices to choose from.  Then you evaluate each one, dropping off some of choices for good reasons like feasibility, cost, alignment, schedule, and risk.  This happens at a 'reduction point'.

    Each time you do this, your number of design choices is more constrained, and your reduction cycle brings you to a narrower range of choices.  After a few cycles, you get a choice that you can live with and you commit to using it.

    image

    The amount of time that this process takes does not have to be any longer than the normal design cycle, especially if you are using agile principles and you have the customer close by.  You don't commit to expensive and time-consuming technical prototypes until about the third cycle. 

    The first expansion cycle is done on paper and white boards.  Same for the second one.  Sketch.  Scribble.  Be creative.  Wave arms.  Use the cheapest, quickest, most flexible tool that will work.  Paper is good.  Some folks have adapted tablet input devices for sketches.  That's a pretty good idea, IMHO.  Just keep it creative.

    Design is not only for user interfaces

    One beef I have with many discussions of design is the notion that this cycle of creativity is really useful for user interfaces, without much discussion of how to use this concept for system architecture.  The reality is that the architecture of the system is a construct built through the creative use of various architectural and design patterns. 

    When sketching out design choices for system architecture, you can consider different patterns for integration, data management, logical representation, rules management, flexibility, cross-cutting concerns, etc.  It is just as creative, but the effect on the final product is not visual, but rather a quality effect.   Your system quality attributes benefit: flexibility, reliability, scalability, security, throughput, etc.  So don't take the things I'm saying as "applying only to user interface design."  I include U/X but do not limit the use of design to U/X concerns.  It's a good method.  Use it everywhere it works. 

    Understanding what customers value

    When you are looking for business value, you have to look for any changes in measures of value... things that our six-sigma friends call "CTQ" or "Critical to Quality."  These are "the things that are important to the users."  When you listen to your customers, you find out what is important to them.  Don't assume you know.

    This is more than collecting requirements.  This is about finding out what the customers think is important... what they value.  Look at the decisions they have made, not just the things they say.  Listen to their language, not just their words.  If someone is effusive about using "simple software with limited choices" but they use really complex software on their desktop, then drill in... there's more there. 

    Understanding the customer is the first step in designing a solution, because only when you know how to measure your success in the terms that the customer would recognize, only then can you be effective in selecting a good design.

    The business value of meeting customer value

    Customers don't share all of their requirements with IT, even when it is in their best interests to do so.  (Obvious, right?)  But who is to blame for failing to capture requirements?  Both of us.  We get so wrapped up in functional requirements: the things the system has to do, that both customers and software folks can lose track of the intangible yet important things that drive purchase and use decisions: feel, crispness, comfort, friendliness, ease, and a connection to the metaphors that the customer is familiar with.

    This is what Apple got right with the iPhone and what Google is chasing with their personal device.  This is why Amazon's Kindle is pretty cool... not just because these devices are simple, but because they are appealing.

    Example 1: Here is what happens when you deliver software that works wonderfully well, but no attempt was made to create elegant design.  Note the milestones: how frequently does the user have to request an app?  Also note that I indicate the time between funding a new version and getting it. Are they happy with the app when they are waiting for the next version?  Maybe, maybe not.  IMHO, the answer is quite often "no."  This is the unhappiness that drives cost. 

    How much money does the enterprise spend on this app over it's lifecycle. 

    image

    Example 2: Here is what happens when you deliver software that works well but feels great too.  Some things to note: fewer requests for change, and further apart.

    Consider the cost argument: how much does enterprise spend on this app over it's lifecycle?  More or less than above?

    image

    The total cost of ownership (TCO) includes costs incurred to maintain and update an application for many cycles.  The longer an application goes between cycles, the lower the total cost.  And an investment in good design can dramatically stretch out the time between maintenance cycles on an application.

    Therefore, it is cost effective to spend a bit of time using creativity in developing new applications, not only in user experience, but also in the structure and patterns of the application's architecture.  The cost of any one project may be affected (or not) but the TCO will go down... and that is what we all pay for.

Page 1 of 1 (4 items)