Gabriel Morgan

Business Software Platforms are not Strategic

I want to share an idea that occurred to me and some of my colleagues, Dave Langer in particular, that was triggered during the work in building our business system architecture to enable our S+S corporate strategy, which is that reusable Business Software Platforms are not Strategic. In fact, if anything they are the opposite of Strategic.

Note: Before you read further, I recommend glancing at the Glossary of Terms at the end of this post to brief yourself on the definitions of Business Strategy, Business Process and Software Platform.

Essentially, the idea is a simple 3-step process which starts with Business Strategy and ends with candidate logical descriptions of Business Software Platform that, interestingly, are deliberately not directly enabling Business Strategy. Here’s the process:

Step 1. Identify the Business Strategy

A business must identify what its Business Strategy is. With methods like Michael Porter’s “Five Forces Concept” and/or Jim Collins’ Hedgehog Analysis, a business can identify its Business Strategy.

Porter’s Five Forces Concept		Collins’ Hedgehog Concept

One output from this activity is a set of Business Strategy Statements where each Business Strategy Statement includes Objective, Scope and Competitive Advantage elements. Here’s a link to HBS article describing this in detail.

Step 2. Identify Context Business Processes

Using Business Processes, often in the format of a Business Process Categorization model, identify Business Processes that do not directly enable Business Strategy. There are many methods out there to help do this such as Geoffrey Moore’s Core versus Context, and your common Enterprise Architecture mapping Business Process to Business Strategy activity.

In the Core versus Context method, I refer to the “Core versus Context” concept developed by Geoffrey Moore. In Moore’s book 'Living on the Fault Line', Moore described a method for identifying Core and Context Business Processes and Business Process Activities, "For core activities, the goal is to differentiate as much as possible on any variable that impacts customers' purchase decisions and to assign one's best resources to that challenge. By contrast, every other activity in the corporation is not core, it is context. And the winning approach to context tasks is not to differentiate but rather to execute them effectively and efficiently in as standardized a manner as possible."

In the Business Process to Business Strategy Analysis method, one analyzes the Business Strategy Statements and associates Business Processes that directly relate to Business Strategy Statements. I add a little twist here and assert that Business Processes that do not directly enable Business Strategy are considered Context Business Processes.

The assumption at this point is that Business Processes that are strategic should expect change. Those that are not strategic, therefore Context Business Processes, should expect less change. In fact, according to Moore, Context Business Processes should be standardized.

Step 3. Identify Candidate Platforms

We now need to identify Business Software Platforms. There are number of methods out there to help logically group Functions by Information entities to identify candidate Software Platforms. Methods such as Affinity Analysis, Yourdon and Constantine’s Functional Cohesion, and Coplien’s Scope, Commonality, Variability Analysis. All three have a common goal when using Business Process and Data as factors to be analyzed which is to mathematically identify logical groupings of processes based on their relationship to data.

The only addition I make to these methods is to only focus on Context Business Processes in the analysis. The assumption I make is that Software Platforms, by their very nature provide reusable/shared automation of business processes and data, represent standardized processes and data. By focusing on Context Business Processes, we simply realize these as Business Software Platforms as a result of the analysis.

Core Business Processes are left to be supported/automated by the more agile Applications because Applications are not specifically designed to be shared or reused. Applications provide time-to-market agility to the business.

Summary - Nothing new just putting together known concepts

This is an interesting post for me because I haven’t introduced any new concepts to suggest this new process idea for maturing the Enterprise Architecture discipline. Instead, I pulled together known concepts from business and software engineering domain experts to form a simple 3-step process for identifying Business Software Platforms.

I’m an Enterprise Architect so I also wonder if this idea can be broadened beyond S+S to across the Microsoft’s enterprise and, potentially, for any enterprise so I thought I’d publish this idea and share it. Thoughts?

By the way, I realize that this simple process is far from easy as there are lots of prerequisites to complete it such as; Defined Business Strategies exist, an inventory of business processes, an inventory of Business Data, and a mapping from Business Process to Business Data. Sorry if I’ve presented it in a way that appears way too easy. :)

Glossary of Terms:

Inappropriately comparing Building Architecture and Software Architecture

Mike Walker wrote a great little article describing that it is largely inappropriate to compare Software Architecture and Building Architecture professions - see here. I think Mike has a great point that the two types of architecture disciplines are so different that it's hard to rationally compare the two.

Mike's blog reminded me my wife's comments on article titled "If building architects had to work like IT architects" written a couple of years ago. By the way, my wife is a commercial and residential Building Architect. Anyway, in that article, Katheryn felt it inappropriately assumed similarities of Software Architecture and Building Architecture to the point she felt compelled to comment and help explain that the article's author is probably not too knowledgeable of the Building Architecture profession.

Note: Although I feel it is largely inappropriate to compare the two professions, I wish we could. Unfortunately, as Mike points out, Software Architecture is just way too immature a profession at the moment.

Here's a repost of my wife's comments to the "If building architects had to work like IT architects" article. Katheryn Morgan wrote:

"The article is misleading because your IT projects are better related to a commercial non- personal project. Your clients would be equivalent to a developer not an individual looking for a personal residence. It can be done different ways, but this way is very common:

Initial Design

If the client is really unsure of what he wants and only has a vague idea and he wants to see some ideas first then he is paying for the head designer's experience. The team is made up of different experienced architects and workers. Each person's time is charged to the client at a different rate. Just like consulting, we have to assign our time to each project. The head designer would charge more per hour than the person assigned to draw it up. The more re-draws based on the clients wishy-washy-ness the more money they are being charged. The client is charged for mileage for site visitations, city department visits etc. Once a design has been agreed on (the project can easily be, and often does get nixed because the client has not acquired the site for the project or the investors have backed out or there are problems with the city allowing such project etc. You can convert any of these problems into your IT world I'm sure) then there is a next phase of costs.

Documentation Phase

The client will be charged by how many sheets of documentation is required for the project to go to a contractor to get sufficient bids for cost of construction. The lead architect by experience should know how many sheets would be required based on the size of the project. The client is also charged for all printing and mailing costs.

Construction Documentation Bidding

The documents are sent to several prospective contractors chosen by the architects and sometime by the clients, as they have probably worked with some before and others chosen because of their direct experience with this particular type of project. The builders bid this project on the hopes they will receive the project and no money is charged by them. The winner is the one who comes back with the best realistic construction cost and can generally show a realistic construction time line with milestones that they are held accountable for and they receive partial payments as long as those milestones are reached. There can also be a bonus incentive for them to finish on time (which rarely happens). This process is kept in strict confidence and the architect never reveals to the other builders what the others bid was.

Construction

Here is a key point different to your world: the designers and the constructors (builders) are different entities. The architect’s role here is to see to the client’s BEST interest. the architects answers RFI's and does site visits to ensure the vision of the project is coming to fruition. The architect answers requests for payment by checking if the milestones have been met, reporting progress to the clients and if the client is satisfied he will approve payment, and the architect will pay the builder.
At the end of the project the architect does a walk thru with the client and builder and any things that need fixing are written and given to the builder. He has to finish these last things before a certificate of occupancy is issued and the builder is given his last payment and any incentive bonus. The architect is also in charge of getting all permits from the city and any official requirements so the client can easily transition."

Enterprise Solution Architects and Leadership

I strongly believe that Leadership is a critical competency for successful Enterprise Solution Architects. To some, that statement may seem bold. To others, its obvious. for those that this seems bold, I hope this blog post helps explain why Enterprise Solution Architects have strong Leadership competencies. For those that this statement seems obvious, I'm simply attempting to refine this concept to bring it to a more mature level.

A bit of my background leading to thoughts on strengthening Leadership competencies as an Enterprise Solution Architect

During my career as an IT guy, I've always been laser focused on my career mission "Improve IT's business value proposition". This is my passion and it is my guiding principle for making career choices. It's worked well for me probably because there always seems to be new opportunities to explore and deliver more business value such as; exploring different software delivery models, exploring different software design processes and techniques, implementing new and exciting technologies, engineering business architecture, and scaling to enterprise-level constructs like enterprise architecture frameworks and organizational dynamics. In fact, I feel lucky to have been able to achieve so much and still be totally inspired to learn and grow more.

My career has taken me through many IT roles gaining experience as an IT software engineer, tester, business analyst, project/program manager, and solution architect.  I've carried pagers while in IT operations support roles. I've spent time in sales selling software solutions and I've spent time as a consultant delivering software solutions and coaching customers and partners how to deliver software solutions. Because I've always had a hankering to make bigger, broader, enterprise-wide business value from IT, my career has led me to where I sit today, an Enterprise Solution Architect.

Enterprise Solution Architects require Leadership skills the most

I think that all Architects require Leadership competencies to some degree but one Architect type that stands out as being the most dependent on Leadership is the Enterprise Solution Architect. Because I haven't seen an attempt to articulate the Leadership abilities in the context of the Enterprise Solution Architect role, I thought I'd share my opinion of what they might be.

So, here's how I think of Leadership. Leadership is a competency and it can be decomposed in a number of ways; leadership principles, habits, values, emotional intelligence abilities, leadership imperatives, frameworks, competencies, et al. All are valid and often share the same semantic meaning but conveyed in different terms and constructs giving us lots of choices to find the one that resonates with each of us individually.

Daniel Goleman's Leadership model as the base construct

One such Leadership model that resonates with me is Daniel Goleman's Emotional Intelligence (EI) abilities organized by the domains Self-Awareness, Self-Management, Social Awareness and Relationship Management. The complete list of Goleman's EI abilities with definitions are located at the end of this blog.

This is an Architect's blog post, so I created some views of the EI domain model as well as the actual model using UML notation for those who like to read models:

Leadership Object Model

Relating Goleman's Leadership Competencies to the Enterprise Solution Architect

So, how does this all relate to the Enterprise Solution Architect role you say? Well, I think that this is where things get fascinating. Below is an attempt to describe how Goleman's Leadership abilities relate to the Enterprise Solution Architect role. It is very rough but my hope is to mature the thinking to the point we can manage Leadership abilities like we can with other Architect skills like I described in this blog post regarding growing Solution Architects.

It should be noted that the Enterprise Solution Architect's Leadership competencies are required or be the highest maturity achievable. The aim of this blog post is simply to describe the relationship between Leadership competencies and the Enterprise Solution Architect role.

Just some closing notes

There is nothing new described in this blog other than an attempt to articulate a relationship between two concepts. It is my interpretation of the fantastic work already delivered by Leadership thought-leaders in the context of the Enterprise Solution Architect role.

Acknowledgements: One of the great pleasures from working at Microsoft is the opportunity to work with unbelievably talented people. One such person is Harry Tucker and a few others whom I'm not sure I have the right to publicly identify...Jeremy, Mike, Chad and Gray. ;) Anyway, much of what I've written below was directly triggered by their coaching and I'm very grateful to have crossed paths with these individuals.

Here are Daniel Goleman's Leadership Competencies:

Achieving Model Traceability: Finding the Traceability Critical Path

We all agree now that Adoption is key for Enterprise Architects. And the trick to adoption is resonating with those that make change and influence them to make the change that is best for the enterprise. In a previous blog post, I introduced the Solution Model concept. In this post, I want to talk about the concept of the Traceability Critical Path, which is the portion of the Solution Model necessary to trace from Strategy to Code.

Support for Solution Architects is good

As Solution Architects, we have the ability to understand a business problem and be able to derive a software solution to meet the business problem. We have lots of process tools to help us such as software development lifecycles like Microsoft Solutions Framework (MSF), Extreme Programming (XP), Rational Unified Process (RUP) to describe who does what and when. We have methods such as Object-oriented Design (OOD) and Attribute-based Design (ADD) to help use design software components. We have vibrant software engineering organizations and user groups like IEEE, OASIS and Software Engineering Institute (SEI) to leverage. We have knowledge bases to leverage such as the Software Engineering Book of Knowledge (SWEBOK). We have system design tools such as Visual Studio to design, develop and deploy software. Pretty good.

Support for Enterprise Architects is good

As Enterprise Architects, we have the ability to understand all of our business organizations and derive IT architecture for the entire enterprise. We have lots of tools to help us such as Enterprise Architecture Frameworks (EAF) like Gartner's EAF, TOGAF, Federal Enterprise Architecture (FEAF). We have industry organizations and user groups to leverage such as ISACA/COBiT, ITIL and TMForum. We have methods to identify and focus on individual business pain points like MSBA's Business Capability Analysis and Six Sigma/Lean to avoid analysis paralysis. We have tools to help manage enterprise information such as business processes, project and application portfolios from Microsoft, Troux, MetaStorm and Sparx Systems.

We need a way to connect Enterprise Architecture to Solution Architecture

So, here's the problem, the outputs of all the tools and methods need to be connected so that we can trace from "strategy to code". You may have heard other catch phrases trying to say the same thing such as "connect planning and implementation", "deliver to the plan" or the phrase "help an organization determine the right things to do and ensure that project teams do them right". Isn't it funny how there are so many catch phrases out there trying to describe the concept of Model Traceability?

Model Traceability connects Enterprise Architecture and Solution Architecture

My team thinks that Model Traceability is very important and we have invested in this area to help us make sense of all the tools and methods out there in an effort to streamline what's important so that we can honestly and justifiably say we know what are the right things to do and we can trace them to project teams and show how they are doing them right. During this effort, we have discovered some very interesting things.

We evaluate the tools and methods and identify what concepts they produce or mange. We then evaluate these concepts and determine what value they bring to their stakeholders; concepts such as Business Strategy, Business Capability, Use Case, Business Process Activity, Application Interface, System, Code, Test Case. We then determine how they are associated to each other. For example, A Business Process composes Business Process Activities. Automated Business Process Activities use Applications.

Without the metamodel, we might have a mess like the diagram below illustrates.

Disclaimer Note: The diagram above is not representative of my team's metamodel in order protect Microsoft IP. I deliberately used inappropriate elements, removed several elements, removed all associations between the elements, and spatially organized the elements somewhat randomly.

There are lots of concepts involved, we need the Traceability Critical Path to understand the explicit connection

Our goal is to get to what we are calling the Traceability Critical Path. The Traceability Critical Path (TCP) is the set of lowest-level elements in the metamodel that have an explicit association with each other that are necessary to trace from Strategy to Code. [I know, bad acronym choice. We might later rename it to avoid confusion.] Identifying the TCP elements and how they relate is the goal of this work. Then, connecting the rest of the elements to the TCP elements to understand how they relate.

Along the journey of defining the TCP, we discovered some interesting characteristics of the metamodel elements. We found it useful to differentiate between element types. Here are some examples:

• Traceability Critical Path elements. Elements that have a direct or concrete relationship from planning activities
• Enabling elements. Elements are really only methods or tools to derive critical elements.
• Temporal elements. Elements that act as placeholders for required elements but are needed at a later time in a process.
• Discipline-specific elements. Elements that are useful only to certain disciplines but are somewhat meaningless to others.
• Associations elements. Elements that describe how elements are related/associated with each other.

We had some interesting observations made along the way worth sharing

Along our journey we made a few interesting observations that maybe, at some point, I'll dig into later because each could take a while to explain. But for now, I'll just jot them down to share:

1. Complimentary Information Model. In addition to the metamodel, we created an information model to describe the concepts the elements represent because there are times when identifying individual elements, the resulting element's names don't easily resemble the original concept being evaluated and causes a bit of confusion. We required an information model to describe aggregations, compositions, generalizations and subtypes to keep the metamodel meaningful by the different audiences.

2. Enabling and Temporal Elements and Abstraction relationship. We observed during the exercise of building our metamodel that the relationship between the Enabling Elements and degree of abstraction. We noticed that many of the Enabling and the majority of the Temporal elements tend to exist at higher abstractions and the TCP elements tend to fall in the lower abstraction. This trend is illustrated in the graph below.

3. Gaps in enterprise planning concepts. When analyzing the trend data, we found gaps in our scatter graph. We are wondering how to explain this and what to do with this observation, but we are leaning to spend a bit of time to apply some engineering rigor and define enterprise planning concepts in more detail. The types of concepts are those that describe Business Strategy and Business Model as examples.

Summary - The TCP brings very interesting benefits

Having the metamodel and clear identification of the TCP within it, we get a lot of benefits such as:

1. Objectivity. Ability to put the tools, methods and concepts from several disciplines into perspective and help us get to the crux of their value proposition to enabling elements in the TCP.
2. Impact Analysis. Ability to traverse the model and do Impact Analysis from any element of concern. For example, one can identify which applications are involved to enable Scenarios. Or, one could identify which System Features impact Customers or Business Partner and so on.
3. Role Clarity. Ability to understand the disciplines and roles that typically create elements fit into the planning and implementation activities.

I would like to share our metamodel, complete with the TCP, as well as the process used to build it. But, to be fair, this is a team effort and I want to give credit where credit is due as well as respect the fact that this is the property of Microsoft that I don't have approval to publish yet. If you'd like to see our metamodel, let me know and I'll bring your request to my team.

Valuing the Undervalued Solution Model

Modeling helps improve the success of delivering a high-quality solution

A primary responsibility of a Solution Architect is the integrity of a given project’s software solution. There are many aspects to a solution’s integrity such as System Quality as well as Traceability to ensure the software actually meets the business needs. There is another that is the topic of this blog post and is a Solution Model. Of course, a model by itself won’t guarantee a high quality solution or traceability. However, if done right, it could and it could help you get there faster.

Keep it simple – Use modeling to describe the problem, the solution and how they relate

Let’s sync on the term Solution Model. It's actually quite simple. I’m referring to the concepts or artifacts a project team manage that:

1. Describe the business problem. For example, concepts such as Business Process, Customer Scenarios and Requirements.
2. Describe the solution. For example, concepts such as System Features, User Interfaces, System Interfaces, Data and Source Code.
3. Describe how they are tied together. This bit is really important. This is where you define how the concepts are associated for Traceability. For those familiar with Software Factories, this is similar to the concept of a Software Factory Schema.

Getting modeling adopted is hard

Project team members naturally think myopically and avoid contemplating the needs of other team members or groups that depend on their information. Because modeling a Solution Model requires tying all the concepts together across the project team, you can imagine the many challenges to get it adopted by the project team. For example, here are few challenges a project team might face during efforts of gaining adoption:

1. Proving the model’s value to the business stakeholder’s to get buy-in isn't easy. Without business sponsorship, getting modeling adopted by the entire project team will be a tough hill to climb.
2. Proving the model’s value to the project team to do the actual modeling. Ideally, everyone will build their portion of the model as part of their responsibility of solution delivery. The challenge is to get the team to do it, and proactively.
3. Determining the role of the model in a project. This is really important, many modeling philosophies out there assume a model-driven approach. I don't agree with this assumption. Modeling has several dependencies that dictate the value modeling brings to a project. For example, models can be use to kickstart the architecture (think MDA) and then it could be, and appropriately so, discarded. Or, it could be used to drive the development (think MDD) with roundtripping, therefore living throughout the lifecycle of the project. Or, it could be used for reflecting what’s already in place for maintenance activities post release of the solution.
4. Determining the right level of model maturity for each model. This is about understanding how much rigor will be spent on the models to establish expectations of what the models will accomplish without compromising the model integrity. This is a project-by-project decision, heck, even a model-by-model decision when you get down to it. The important point to remember is to make sure the level of maturity isn't too stringent while at the some time the level isn't too low that it doesn't compromise the integrity of the Solution Model.
5. Having modeling skills and modeling tools available to the project team to do the actual modeling. It seems simple but the reality is this can be a big challenge. I suggest short simple modeling activities as a start to benchmark the team's modeling skills and work from there. Once the initial kinks are worked out, look to automate the modeling process with a modeling tool. Oh, there always seems to be the need for a modeling SME - someone to the hold modeler's hands, manage the model repository and do brownbag training sessions. It's good to keep this in mind and allocate resources just in case during project estimation and team readiness activities for a dedicated modeling SME.
6. The right number of modeling tools. There will also be multiple tools in play. For example, business representatives will prefer business requirements requirement management tools like Visual Studio Team System or Compuware. Business process people will prefer specific process modeling tools like Provision and Corporate Modeler. Information Architects will prefer Erwin or Enterprise Architect. System Architects will prefer Visual Studio Architecture Edition or Enterprise Architect. Tools are a personal choice to most people. My advice to you is to allow people to choose their own modeling tool AS LONG AS:
   • The tool supports XMI import and export and
   • it is an actual modeling tool, therefore, no word editors, spreadsheets, slide decks, etc.
   • there is a single proper modeling tool which the Solution Architect can use to collect (via XMI import) the other models into a single tool and associate model elements for traceability

It’s not about modeling philosophy – focus on the aspects of modeling that bring value to the team

This blog post is not a stroll down theory lane. Although theoretical Modeling concepts, scientific modeling philosophy or modeling methods and paradigms such as MDA, MDD, UML and DSM are interesting, they are about how to model. That is, modeling methods, modeling diagrams and modeling notation. Instead, this blog is about understanding the value of modeling to a project team and is focused on helping Solution Architects gain a practical understanding of the value of modeling to, in turn, help explain its value to the project team for adoption. Because, in the end, without adoption theory is pointless in our efforts to improve system quality and optimize the business investment.

Sidebar: A Model is not the same as a Diagram. There always seems to be a bit of confusion around this, so I thought I’d make this note. A diagram is merely a View or picture. A Model ensures that the model elements on a diagram have specific meaning in both what they represent and how they relate to other model elements. There could be diagrams of a model but if the diagram doesn't have an underlying model to ensure integrity of the model elements, it is only a picture. Although a diagram is useful, it can be misleading because it is probably inaccurate and only represents a point in time.

Models provide tons of value – the trick is describing it to the project team

So, what's the value of the solution model? Below is a list of value statements to try and answer that question and is the main purpose of this blog post.

1. Consistent Terminology bringing clarity and team scalability. Models provide a consistent language for describing the business problem and how the solution will address it bringing clarity to the entire project team. When resources talk about concepts like Business Process, Scenario, System Interface, etc the entire project team is crystal clear what those are and how they relate to other concepts. This also makes it far simpler to get additional resources ramped up as the project team grows.
2. Team Focus. Improve the focus of the delivery team to solving the business problem and not get sidetracked or distracted. If the business problem is modeled well, the development team is more likely to understand the challenge at hand and avoid misinterpretation of what the business wants. This is unbelievably useful to ensure that the project team build what they need and not superfluous concepts not in the Solution Model or, at least, minimizing additional effort not already clearly described by the Solution Model. Essentially, each model element become work items and higher priority than concepts not useful by other team members.
3. Improves the chances for a highly Functioning Team. Similar to #2 above, with a well-defined Solution Model, a team begins to partition what concepts each team role is responsible for and which concepts they depend on from other roles in the team. Therefore, team members are avoid miscommunication with their work products and avoid unintended duplication of effort.
4. Enhanced Requirements Management through Traceability. This has to do with the ability to easily navigate how pieces of the business problem are being addressed by the solution design. With a Solution Model of the business problem and traceability to concepts that describe the solution, business stakeholders can readily see what bits are being developed that relate to the specific areas of the business problem…and which bits do not. It also enables engineering teams to understand explicitly which portions of the business problem are affected by system design or enabling technologies. This is particularly useful in the inevitable situation when technology limitations are discovered and engineers wish to know which business representatives to go speak to.
5. Reuse resulting in accuracy. Having a model of the concepts the team manage can effectively reuse concepts where appropriate. This is super important. Take the example of a business entity. If you have a data model of the logical information entities, the team can associate processes, business rules, application interfaces, etc to the information entity, therefore, modeling reuse of that information entity. The value is clarity in the information and avoidance of duplicate information entities resulting in information accuracy. This is just an example using a model of information entities in the solution model. The same could be said for application interfaces, business process activities or any other concept.
6. Early warning system. Ability to perform litmus tests if the solution meets the upstream business strategic goals. Assuming an agile development approach, the solution model implicitly contains traceability from business goals to the solution allowing visibility of the solution bits to be tested and proven effective on the business goals early in the project lifecycle.
7. Reduce Risk of Scope Creep. Requirements are less likely to sneak into the project scope unnoticed. Including requirements as part of the solution model requires that they be associated to other concepts. Where there is no association, automated model integrity checks would easily identify rogue Requirements.
8. Reduce Risk of Project Slippage through the ability to keep the team focused on specific artifacts. A byproduct of having a Solution Model is a clear understanding of what the various concepts a project team will manage and what needs to be done with them and when. This helps reduce unknowns or ‘learning as you go’ that can happen ultimately helping keep the team on track and focused on the specific concepts throughout the delivery lifecycle.
9. Description of the entire business problem. A Solution Model provides a complete description of the business requirements. I’ve bold-italicized requirement because I want to stress that a requirement is simply a generalized description of the problem. It can take the form of process, use case, scenario, CRC or your traditional functional requirement, or something else. The point is that the model describes explicitly which of these will be included giving the model, once filled-in, a complete picture of the all-up business problem to solve.
10. Enhances Requirements Management. The Solution Model allows Product Managers to manage a finite set of requirements for requirement change control activities. A Solution Model also quickly identifies which portions of the solution are affected by new requirements or changes to an existing requirement.
11. Description of the All-up Solution Architecture. Obviously, with a model of the business problem and the solution all tied together, you have a complete model of the solution architecture and can create useful views/diagrams that show the all-up business problem, system model, data model, user experience, interaction models, integration model, etc. A well-organized model also allows for views that show how design patterns are implemented to justify and prove system quality. This is a very powerful value proposition. Consider each project team role and from their perspective being able to traverse the solution model in any direction to get a complete understanding of how other areas relate to concepts of your concern. For example, the Test Team may wish to link Test Cases to Source Code, Use Cases, User Experience Processes and Functional Requirements concepts. A Solution Model inherently provides this. Now, when Test Cases pass, the entire team will know what source code passed and what business requirements and user experiences are now enabled.

You might be wondering about where Project Documents fit into this story. A Project Document, in my opinion, is nothing more than an artifact created for sign-off. I don't think that there are Project Documents that must be created for every project. Identifying which Project Documents to create and their purpose is a decision by the project team directly. There is no hard rule which to use for all projects. Now, what goes in them, I care deeply about. The content of any Project Document should reflect that model. Therefore, a Project Document composes model elements via Views that are designed for a specific set of Stakeholders and their Concerns. Ideally, Project Documents are built/populated from the Solution Model to ensure that the content is accurate.

Here's a simple diagram illustrating how Model Elements, in this case a Requirement, Use Case and Process Activity related to a Project Document using UML notation.

In Summary – a Solution Model is highly valuable. It is worth the effort to get it adopted by the project team.

I covered a lot of ground in this blog post and am talking about an area of modeling not well addressed in the industry. There is tons of information about modeling but little to no information about the business value of modeling nor how to get it adopted by a project team to help a Solution Architect be successful ensuring that a high-quality solution with integrity is delivered. Remember, there are lots of challenges to get a Solution Model adopted. But I hope that through the list of value statements, you will be able to convince your audience to adopt the Solution Model.

Tips for gaining adoption

I began writing a quick response to Erik’s question in this blog about Architect’s high-order bit is Adoption. Erik asked the question how to get people to adopt ideas and before I knew it I was over a page in my response because it was a lot of fun to answer it so I decided to make the response an individual blog post.

@Erik, fun question and thanks for asking.

Maybe I should respond using the typcial 'carrot' versus the 'stick' approaches. The carrot being an enagement between an Architect and the team that has obvious value to those s/he influences. The 'stick' approach resembles a policy-enforcer.

I've been down both paths and currently think that the carrot is the path of least resistance resulting in greater adoption. So, instead of focusing on the 'stick' approaches, let me talk to you about ideas how to acheive results using the carrot approach.

Disclaimers:

1.      I'm not saying that the stick approach cannot be successful. I think that the stick approach requires a lot of organizational and cultural characteristics that finding such an organization with these prerequisites is very difficult.

2.      I’m also not assuming it’s an all-or-nothing situation. Clever Architects appropriately use both approaches. I will say that they often lead with the carrot approach.

Ok, now for some tips to help you gain adoption of your idea in no particular order:

1.      Gain trusted advisor with the business(es) that drive the project. If you are able to build strong relationships with the business leads that control the description of the business problem, you will be able to:

a.     Help them articulate the problem in such a way that

                                          i.    It desciribes the area of the solution architecture you are most interested in influencing. There are always times when the business wish to achieve a goal but focus more on areas of the business problem that meet their concerns and detail these needs. What can happen is that the business gloss over areas that are not focus areas of the business problem, leaving a bit of ambiguity or wiggle-room for interpretation that may result in a poor-quality design in the solution.

                                         ii.    May implictly suggest how to solve the business problem that naturally includes a particular idea you have about the Solution Architecture. If you are able to have the business clearly describe Business Requirements that layout the need for a high-quality solution design idea you have, you will have the ability to ensure that the solution delivery team explicitly meet these Business Requirements by adopting your design idea.

b.    Ask for their support in driving architectural change in the direction you wish. If you find yourself in the position the design team have built a poor design to solve a loosely described Business Requirement, you must be able to articulate the business ramifications of the poorly designed solution in terms of financial risk, Customer experience, Supplier/Partner experience, etc to raise awareness and appreciation of the design. Then, naturally suggest architecture options you have to help solve the problem and work with the business to help drive them through the project team. This can get quite complicated because of the dynamics of the project team. Normally by this time in a project’s lifecycle much of the scope is locked, estimates are done, resources committed, etc so getting these types of changes pushed through will require a very good explaination as well as a good bit of politicking to make sure that the business leads and project leads support your idea.

2.      Contribute to the design of a project’s lifecycle process. I don’t necessarily mean that you are a part of the lifecycle process therefore someone who requires sign-off before a team can continue. Being a Sign-Off Owner is always fraught with pain and I don’t suggest this approach - it normally falls in the ‘stick’ approach and I prefer to stay away from this. What I am saying is to help the team build a project lifecycle process derived from your favourite methodology/technique/framework like Microsoft Solutions Framework (my personal favourite). Ensuring the team adopts the process that enables them to function together in a complimentary fashion is huge value to you.  In fact, I believe that getting the team to function together is onf of an Architect’s prime directives. Help the team to be able to easily declare when an individual is out-of-role or is not performing their function. When you have an idea that you wish to be adopted, you can rely on the project's process model and team model to gain adoption. If a team isn’t functioning correctly, any silverback/alpha-dog personality can bypass any process and ignore you and your idea…or anyone elses for that matter. Very Bad.

3.      Steward the models. Let’s face it, he who maintains the minutes writes the facts. All projects will require some sort of documentation. The key is to offer up skills and resources to help document it and, coincidentally all the way, you get the opportunity to suggest how documentation might be done to a) have consistency in the documentation and b) communicate it. Offer to take the burden of managing the model repository and be the modeler for the documentation. This is a really powerful technique to gain adoption of your ideas because as model-monkey, you:

a.     Are invited to most meetings to document the discussion so you are well-informed and are present to help influence decisions.

b.    When documenting via modeling, you gain integrity in the documentation via integrity of the models. This assumes you are using a proper modeling tool not what I call a ‘picture tool’. You get to spot poorly written requirements ad designs and articulate them via the model. This helps prove the value of the models and your role to steward them.

c.     Caveats with this technque. If the modeling tool doesn’t allow for the models to be easily accessible and easy to use then you run a very big risk in the models not being used or referenced. When this happens, you also lose credibility and diminish your trusted advisor position. Be very careful when and how you apply modeling tools.

4.      The Architects Middle-out Strategy. Ok, maybe mangling the term ‘middle-out’ too much here J. What I mean is to start with the Leads and work out from there. Avoid top-down and bottom-up, that is, Executive-down and Individual Contributer(IC)-up respectively. Gain trusted advisor for the managers with accountability that do the actual work in the area you wish to change and they will help you manage-up and manage-down. They are often the ones making the decisions that inform executives. They are also the ones who delgate the work to ICs. Partnering with these folks is critical.

5.      Be selfless NOT selfish. We all have vision and ideas to be adopted. The key for an Architect is to find a way to make your vision and ideas resonate with whomever you want to influence. Don’t presume they care about your vision and ideas. Don’t presume they will explicitly understand them and the value they bring to the enterprise, customer, partner or shareholder. Seriously, this is super important. Always focus on helping them solve their problem. Then, along the way, interlace your ideas with the solution. This goes for efforts that are in planning, execution or maintaining situations. For example, even if your idea is as extreme as stopping an initiative, work with the planning team to understand their motives and goals and then cleverly help them discover your idea and collectively agree that it is in the best interest of the company to stop the initiative. Architecture is, and should be in my opinion, a thankless job. We are about doing the right thing which often means getting others to be successful and having their success recognized. Get used to it J. If, as an architect, you’re keen to be recognized or be ‘in the media’ as often as possible for driving change, you will dissapointed and often.

6.      Understand and articulate your value proposition. Have a crystal clear value proposition to every project team lead and every senior manager of those team leads. I have a rule of thumb for describing value of a role. If you can’t explain the value proposition in 10 words or less and the meaning has obvious value to ALL of the project team leads, you are doomed. For example, here are some basic value propositions which resonate with all leads:

a.     Project/Program Manager: Ensure the project is on-time and on-budget.

b.    Testing Team Lead: Prove the solution works

c.     Development Team Lead. Build the solution.

d.    Release Manager. Deploy the solution.

e.     User Experience. Ensure the solution is usable.

f.     Architect: Ensure the quality of the solution to its stakeholders. This is what I often use, and is an extension of MSF’s definition. It is a bit squishy but good enough in my experience. When people question, what I mean by quality I answer based on their role. For example:

                                          i.    For Project/Program Managers, it is the traceability of the business problem to the solution to ensure no wasted efforts and to make sure we are solving the business problem and that the solution nicely fits within the enterprise environment in which it will be deployed.

                                         ii.    For Testing, it is the explicit focus on the solution architecture to optimize system quality attributes (Performance, Security, Flexibility, etc) that they must also test for in addition to the obvious Functional Testing.

                                        iii.    For Development, it is the explicit focus on the solution architect to optimize system quality attributes to meet the needs of the business owners and IT system admins as well as align to the long-term direction of system integration needs of the shared enterprise systems.

                                                           iv.      Etc      

7.      Daily Build. This tip applies the Daily Build principle from MSF. In this context, I mean publish models and diagrams every day allowing you to get your latest thinking out for others to use (i.e. adopt) and provide feedback. You will gain a number of advantages such as:

a.     Heartbeat. Your architecture diagrams will show life through a regular publishing and increase your chances of being seen by other groups used improving expectations that you deliver quickly and regularly.

b.    Accuracy. By building every day you iterate on the architecture and include the latest impacts of deliverables from other groups such as scope changes, technology choices and involved user groups.

c.     Avoid the ‘Big Bang’. You do not want to fall into the trap of waiting for the all requirements or all technology decisions or all whatever to be made. There will always be changes in the things necessary to build the solution architecture. By the time all of these decisions are made the solution will already be done and your ideas for adoption are moot.

This is a good start to the list. I’m keen to collect other tips to add to this blog. If you want to add one, please comment and I’ll post it to this blog.

SaaS Service Offerings redefine what's in a product

As I continue my work on my little nook of Microsoft's S+S business strategy, the team I work with has noticed something peculiar about what exactly a Service Offering really is. Because we know the packaged software business so well, we sometimes overlook what at first seems like a subtle difference in the SaaS business but eventuates into something quite substantial. One such situations is the understanding of what a Service Offering is compared to a packaged software product.

Service Offerings via SaaS redefine what a product is

In the traditional packaged software business, product features define what a product is but Customer 2.0 expects to have direct access to operational features within the Service Offering itself.

Take for example Microsoft Word. Product Features such as Import/Export, Mail Merge, Rich Editing, HTML support, Charts and Graphs and Templates are the types of features that Customer 1.0 values most in a product. SaaS Products are much different because Customer 2.0 demands it. Not only must a product include traditional product features, it must also include operational features such as Configure Service, Manage Service SLA, Manage Add-On Features, Monitor Service Usage Statistics, Self-Service Incident Resolution as well. In traditional packaged software products, these features were either supported manually, didn't exist or were change requests to a supporting IT department.

Service Offering = (Product Features) + (Operational Features)

Operational features directly impact the most valuable aspect of the Software Service Provider business...service quality for customer retention. Dr. Nilesh Bhide, one of my esteemed colleagues wrote a great blog post on the value of the qualitative customer experience for a Service Provider business (see here). This is a fascinating reality online Service Provider businesses have.

So, what downstream impacts are there for SaaS products? There are two that I'd like to look at; operational business processes and their supporting business systems.

The operational business processes must now include Self-Service Incident Management and Self-Service Service Management to streamline and enable the direct interaction between Customer 2.0 and the Operational systems to make real-time incident resolution and service configuration changes on the fly. Inability to have these automated business systems result in a degradation of service quality and inevitably customer attrition.

Product Managers of SaaS Service Offerings must include into the Service Offering operational features to optimize customer retention. They cannot be an afterthought nor can they be lower in priority. They are a key 'feature' of the Service Offering itself.

This assumption implies that the systems providing the operational features must also have the highest system quality that product features have. System quality attributes such as system reliability, system security, system performance and system usability. Any downtime, lack of usability or any other poor experience with these features naturally reflect the rest of the Service Offering itself. This is the point I want to make with this article. Guess who builds and supports these Operational Features? Your friendly neighborhood IT department in conjunction with the Operations and Service Offering product group. This raises the quality bar for your traditional IT shop.

Oh, and by the way, these must be provided at a very low maintenance cost so as not to cut into the profit of the low profit-margin SaaS business. As noted in the Wall Street Journal the other day "Microsoft’s troubles in online services grew in the quarter as losses widened – to $245 million – due in part to increased costs of data centers..." ("Microsoft Net Surges With Help From Vista", Robert A. Guth, Wall Street Journal, Friday January 25, 2008). Of course, data center cost isn't the only factor to the $245 million dollar loss but it was a significant contributor. This is a sharp reminder that online Service Provider business must have efficient data center operations to be profitable.

The need to focus quality on the operational features to run a successful business isn't all that surprising. Geoffrey Moore once wrote "For core activities, the goal is to differentiate as much as possible on any variable that impacts customers' purchase decisions and to assign one's best resources to that challenge. By contrast, every other activity in the corporation is not core, it is context. And the winning approach to context tasks is not to differentiate but rather to execute them effectively and efficiently in as standardized a manner as possible." Business processes such as the customer-facing sales, fulfillment, assurance/support and billing are all core because they have direct interaction with the qualitative customer experience.  Therefore, these processes become a top priority in order to be competitive in the online software service market. This understanding is a critical component for software service providers today.

Customer 2.0 is here and she has a major impact on business models and system architecture

One of the major tasks on my plate is understanding the impact of business systems to support the explosion of Software as a service business offerings, such as Exchange Hosted Services, Windows Live offerings and Microsoft Dynamics CRM Live. These business offerings all stem from the 'Subscription' business model built to support our overall Software + Services business strategy.

As I think about the S+S business strategy with my team, we, the Microsoft IT Enterprise Architecture Team, has realized that we must better understand the difference between customer expectations and how these customer expectations influence business models and IT systems. Through our work, we've learned that there is a quite interesting and simple relationship between the enterprise business applications and customer expectations. As we researched customer expectations, we discovered that a new customer profile exists, or is in the midst of existing. This new customer profile has forced the Subscription business model to exist and requires us to have a fresh look at our IT system landscape to support the business model. We have coined the term Customer 2.0 to describe these new customer expectations and this will be the topic of this blog.

My hope in this blog post is that the penny will drop and you will see that a significant change in customer needs has occurred and these changes force a deep and hard look at the supporting IT system infrastructure.

Okay, let's get started. Customer 2.0 marks a significant change in our understanding of the software market. Before describing Customer 2.0, let me first describe Customer 1.0 to help give context.

Customer 1.0 has expectations including:

• Buys complete software packages
• Responsible for software installation and maintenance
• Pays for distinct software upgrades
• Owns and controls data
• Locked-in financially because of large up-front costs to purchasing software
• Delayed usage due to search-buy-ship-install
• Finds it difficult to move from one software package to another

Customer 1.0 is serviced by a more traditional Packaged Software business model which has characteristics including:

• Low volume / large dollar transactions
• Quantitative is more important than qualitative software features
• Indirect customer channel via partners and suppliers
• High barriers to entry and exit
• Fragmented and specialized customer support
• Structured product and price models

Through a change in environmental trends, Customer 2.0 has evolved. These trends have a huge impact on downstream business models and system infrastructure. Some of the environmental trends I'd like to highlight are:

• Increasingly more competitive software market
• Increasing digitized content
• Proliferation of the Internet
• Cloud computing
• Social networking
• Collaborative computing
• Web 2.0 Mashups
• Code-savvy users
• Online advertising as a successful business monetization model

The above environmental trends have forced Customer 1.0 to evolve to Customer 2.0 with characteristics such as:

• Has optional purchase models (flat rate-based and consumption-based subscriptions)
• Pays only for what they use when they use it
• Adds features to the experience seamlessly
• Expects upgrades to be free and continuous
• Swaps providers easily
• Has flexible software budgeting
• Expects a rich internet application experience
• Accepts ad-based features
• Expects Self-service Problem Resolution and Service Management
• Accepts internet/cloud based software that is not installed on-premise
• Has data locally and in the cloud
• Has a direct relationship with the Service Provider
• Instantaneous purchase and activation

These characteristics are incredibly different and force a change in the software business model to service them. Hence, Subscription Business Models has emerged and are a large part of the Subscription business model (near synonymous to the Software-as-a-service business model in my mind), which is key to the Software + Services business strategy.

The S+S Business strategy requires a Subscription business model with characteristics including:

• Dynamic product and price models
• World class IT infrastructure : Reliability and Regulatory compliance
• Customer data is integrated across services
• Progressive levels of feature usage
• High volume / smaller dollar transactions
• Self-Service Problem Resolution
• Regular Service Upgrades
• Customer retention is critical
• Self-Service Service Portfolio Management and SLA Management
• Low barrier to entry/exit
• Direct customer relationship throughout the value chain
• Little customer segmentation
• Unified customer support experience
• Single 360 degree view of customer
• No boundary from features to IT supporting systems
• Subscription/consumption/points/adverts monetization models
• Balance transfers from dollar credits to and from points

This business model is substantial and forces a new, fresh look at the IT systems architecture needed to support it. I've bolded words in the business model which should strike you as important; reliable IT, integrated services, high volume, self-service, unified customer support, etc. These are key attributes of the resulting enterprise business system architecture which I will go into in subsequent blog posts.

The purpose of this post is to level-set on the problem domain which I will address in later posts from the business system architecture perspective.

SWABOK, Archipedia, Uber Architecture Framework, xyz?

Nick Malik wrote blog post "The culture of art vs. the culture of engineering" that described the problem of architects and developers being caught up in invention rather than reusing software system definitions and concepts.

I wholeheartedly agree with Nick. We’ve all struggled with this problem it seems. The situation I observe is when I point Architects and Dev Leads to reference material with the intention of pointing them to reusable content (albeit a design pattern, a design process, reference architecture, reference model, or a theoretical concept), 9 times out of 10 they don’t readily see what it is I meant for them to learn from it. Btw, by learn I mean; a) becoming aware, b) gaining an understanding and b) applying what was understood. A lot of this is dependent on me not being able to convey a message clearly but much of it depends on the recipient not understanding the purpose and context of the problem they have nor being familiar with the material out there to see how the material can help.

Reusing architectural references is not as easy as pointing people to a published copy of documentation. It often involves a lot of handholding and a bit of luck. Only when there is a fully complete, prescriptive methodology to follow that surrounds the nugget of knowledge I find important, do most feel comfortable.

It is rather confusing, let's face it. There are plenty of proprietary and public concepts, frameworks, processes, models and other material that covers bits of the overall knowledge a senior software system architect needs. The problem is that in the nascent world of software system architecture, there simply is no such thing as the uber methodology that explains how it all fits together and be used for all software system architecture planning, designing, building and operation activities from the Enterprise Architecture to Solution Delivery to Operations Support points of view. To top it all off, when a new good idea comes into the fray (eg SOA, ESB, MDM, S+S, System Quality), rarely do people understand how it fits into the overall software system architecture picture. The result is building yet another methodology, process, framework, etc and the opportunity for old concepts to be renamed and tagged as being 'new'. Confusion compounds.

There have been attempts in the scope of software engineering such as the Software Engineering Book of Knowledge (SWEBOK) found here http://www.swebok.org/. This is an interesting attempt at building the uber reference for software engineering. I wonder if we could build on top of or expand SWEBOK to include all software system architecture stuff and reuse SWEBOK to form a Software Architecture Book of Knowledge (SWABOK). Essentially, it would be a place that hosts best practices that is anchored to an information metamodel to help connect them together and help readers navigate between the references in a structured, hierarchical model.

Alternatively, we could build a site structured on the encyclopedia metaphor - sort of like Archipedia that is a wiki-format software system architecture site that hosts all best practices and links them together. This approach is a little less intentional and a bit more open but maybe the right path to take.

Or, maybe we need to go down the path of building another framework or methodology. But instead of inventing a new concept we invent only what we have to and then point to best practices already out there. This would give us the opportunity to build out a comprehensive and prescriptive framework including team model, process model, and risk management, templates, and examples. Of course, this would require a lot more work and a tighter community to ensure consistency.

It very well could be we need a combination of all of the above at varying levels of depth. I don't really know the answer but am interested to hear from others that have an opinion.

Service Delivery Platform (SDP) for the Enterprise

I'm noticing a lot of great improvements in Enterprise Architecture Frameworks, namely FEAF, TOGAF, Gartner EAF and ITIL (Yes, I see ITIL as an EAF now). They are embracing similar improvement themes like Business Strategy linkage, enabling agile business via Service-Oriented Architecture approaches, iterative delivery processes, federated team models, and process, information and system complexity reduction.

The good news is that they are learning. And the bad news, unfortunately, is that they are learning and each new concept they gradually expand and adopt takes a bit of catch-up with what industry thought-leaders already know and it takes time to get new ideas incorporated into EAF documention.

For those of us who have to sign-up and deliver to our CxO executives useful architectures usually anchor, somewhat loosely, to one of the popular EAFs out there and then liberally pull from the best practices that we discover. I'd like to highlight a best practice from a somewhat lesser known EAF called New Generation Operations Support Services (NGOSS) that may radically impact the way your EAF implementation looks today. The best practice is the notion of a Service Delivery Platform (SDP) from the telecommunications industry.

We all know that SOA is a powerful tool to enable an agile business but we don't know what the nuts and bolts, bits and bobs of the resulting well-formed business process, information and system architectures are if we use your typical SOA approach. Well, it turns out that the telecom industry has largely solved this and are working on the challenges of what comes next.

Huh? Am I saying that there's more work to improve our architecture after we get a first serious rev of architecture based on SOA? Yes, there is! Through continuous improvement and change in the business, we will continually modify our architecture to advance our business and be more competitive.

For example, based on the needs of faster delivery of services, there are higher levels of sophistication in how to do Service Management with features like Service Naming, Registry and Location Services, Service Policy Management, Service Quality Management, Service Configuration Management, and Service Rating and Discounting Management.

Another example, is the sophistications in how an enterprise will handle supporting shared services. Enterprise Architectures will need to support shared services and will require sophistications in Dev and Test environments, Governance process and team models, SDLC modifications, Customer Support and Service Consultation/On-boarding.

And finally, there are levels of sophistication how the enterprise architecture will look in S+S scenarios such as process, information and system integration with cloud services. Or, resolve how the architecture will handle partner collaboration and customer-centric challenges the business strive for.

Some may argue that these are already included in a SOA approach - these people are thought leaders and are very rare. For the rest, these bits of sophistication aren't even on the radar yet.

The point is that they definitely are involved and most mainstream SOA approaches out there today don't know this yet. The NGOSS framework is focused on these aspects and through the competitive, free market forces in the telecom industry, they are improving on their framework relatively rapidly. In fact, I predict that enterprises will begin to adopt them and we will see more and more of the SDP concepts built into enterprise products moving forward.

I suggest you take a look at the NGOSS and eTOM documents produced by the TeleManagement organization. Here's their website. Register for free and then start looking at the free material. Pay particular attention to the Enhanced Telecom Operations Map (eTOM), Technology Application Map (see image below), Technology-Neutral Architecture models and Shared Information Data (SID) model that make up the NGOSS EAF.

Of course, NGOSS is more geared to delivery of monetized services than support of an enterprise shared services. But the capabilities they have created to solve for service delivery in a Service Delivery Platform are relevant for the enterprise.

That's my main point of this blog post. I see value in NGOSS/eTOM as a catalyst for improvement in an Enterprise Architecture via, at the very least, a mature Service Delivery Platform to realize SOA. Hence, SDP for the Enterprise.

As it turns out, Microsoft has a strong competency in the SDP space and have a product named Connected Systems Framework (CSF) which is born from the telco industry but generic enough to support an enterprise. Here's more info on CSF: http://msdn2.Microsoft.com/en-us/library/aa445859.

Here's a rough CSF technical architecture diagram to help convey some of the components included in the CSF solution.

Also, have a look at the article "Efficient Software Delivery Through Service-Delivery Platforms" by Gianpaolo Carraro, Fred Chong, and Eugenio Pace found here: http://msdn2.microsoft.com/en-us/architecture/bb735303.aspx

Now, for enterprises seeking to offer Services in a S+S business model, there is much more here to leverage. More on this later.

Adoption, rather than Architecture, is the high order bit for Architects

Over the years I've noticed a strange phenomenon, sometimes the most logical decision isn't the decision made. Have you ever witnessed an unbelievably strong argument to build system infrastructure with all the right scientifically backed architecture documentation, ROI analysis, market analysis and compelling innovation forecasts only for it to be rejected? I have and wonder, why does this happen?

Other than times when an organization simply cannot justify the funds for the right project, there are other reasons for dismissing a sound, scientifically justified system architecture proposal such as:

• Organization alignment challenges are too great. For example, there are times when in order to build the proposed system architecture, organizations must collaborate with each other and this is percieved as an unwelcomed challenge. Think of the situation of building a 'core' system to be used by two or more different organizations, the organizations must collaborate on using them and understand the tradeoffs for sharing a central system. This can often result in a "I'm too different" or "I don't want to take on dependencies" excuse from the organizations involved.
• Not enough politicking or evangelism. I've seen individuals present and gain momentum for projects which deliver lesser value than others...and win. In sales, we call them "spin doctors". They are masters of influence and can get people chanting and believing a simple message without any sound justification.

We've all heard that an Enterprise Architect is a 'change agent'. I go one step further, all Architects are change agents. Let me give you an example, a project Solution Architect's responsibility is to ensure the software quality of the software the project delivers. They constantly influence the project team to build the right software solution that meets the needs of the key stakeholders as well as ensure the the longevity of the software. An Enterprise Architect is responsible for understanding the business' needs and influencing that the right projects are delivered and they have the right level of system quality.

The point I'd like to raise in this blog posting is that simply building architecture documents, whether it be fully fleshed or not, isn't the high order bit for an Architect. Adoption is the high order bit for Architects. Yes, I'm saying that the engineering aspects of an architect's role is not as important as the abilities to gain adoption of their ideas with the sole purpose of making change - the type of change that ensures the business gets the most value from their investment. Of course, if sound engineering is necessary to make change, then the Architect should do this...but only after careful analysis that this is the right thing to spend time on to actually make change.

I'm not saying that an Architect need not worry or spend time on building sound architecture. On the contrary, if an Architect doesn't do this, then I question the integrity of their ideas. What I'm highlighting is to not depend on sound architecture alone to impact change.

Interestingly, in order to gain adoption and make change, Architects must be leaders. Why? Because leaders are influential, leaders gain momentum, and most importantly leaders consciously understand when to lose and win the right battles in order to with the war. And the war Architects engage on is change.

To my fellow Architects out there, remember not to get stuck on engineering excellence. Architects are leaders and we use these leadership skills to obtain adoption and drive change with the sole purpose of ensuring that the business gets the most value from their investment.

The formula for Agility

Months ago I published a blog about how to implement system quality attributes (found here). In that article I asserted that Solution Architects should deliberately design systems for high quality and I provided a means for doing this. Because the point of software, or so I assert, is to automate business processes and protect data quality with the goal of enabling an Agile business, I'd like to propose a formula for determining System Agility.

So, how can we design systems to optimize System Agility in order to enable our agile business? Perhaps this isn't all that complicated if we use system quality attributes. Here's a stab at a formula for System Agility:

A=2(F)+M+I+T+R-P-S

The aim of this formula is not to pretend that one could use it to calculate System Agility with precision. Rather it is more of an attempt to describe how System Agility could be achieved. Using the formula allows me to describe the relationship of key system quality attributes that optimize and degrade System Agility and leave it to the Solution Architect to focus on the relative system quality attributes and implement systems design to optimize or minimize each of the key system quality attributes included in the formula. 

Before I explain each factor, let me cover the assumptions I've made:

1. Agile businesses require Agile systems and the definition I use for System Agility is the ability of a system to be both flexible and undergo change rapidly [MIT ESD 2001].
2. The list of system quality attributes listed at the end of this blog under the label System Quality Attribute Definitions is the finite set of system quality attributes. Yes, I know that this is a false assumption but humor me for a moment.
3. I don't get into the complications of the natural system quality dependencies. That is, for the sake of this formula being very simple, I don't recognize the dependency tree of system quality attributes and their interrelationships and I let each system quality attribute stand on it's own.
4. For simplicity of my key messages in this blog, I focus on the software system only and don't address organizational capabilities nor infrastructure needed to properly deliver System Agility to an enterprise.

Let me take a moment and explain each factor in the equation.

(F) System Flexibility Factor. The most important system quality attribute to enable System Agility is System Flexibility. System Flexibility enables systems to be used in different ways and to be modified for these different uses. It is the means for decoupling interactions between actors. Targeting System Agility, System Flexibility allows software to be reused in ways not thought of at the time of development. I published a blog on System Flexibility, found here, that directly addresses ways to optimize System Flexibility at the enterprise-level. For this reason, I've assigned a multiplication factor to System Flexibility to emphasize the importance of System Flexibility to System Agility.

(M) System Maintainability Factor. System Maintainability is very important to agile software. The key here is code that is optimized for System Maintainability is more likely to withstand changes from bugs that are found and fixed or as well as software that undergoes natural improvements. Software characteristics that are directly pertinent to System Maintainability include; Versioning, Re-factored code, Code Complexity, code structure, etc. 

(I) System Interoperability Factor. System Interoperability brings to the table a focus on interoperating between systems, which is arguable one of the most important concerns for enterprise applications system integration. Software characteristics that are directly pertinent to System Interoperability include; Service Operation designed for uniqueness and extensibility, Message Schemas including those that are canonical, software design patterns that optimize for composability to support orchestration and workflow.

(T) System Testability Factor.  System Testability is important because it forces system designers to make deliberate system architecture decisions to ensure that the software that is produced can be easily tested for delivery. Especially as we see software designed from service-oriented software architecture approaches and S+S needs, the ability to design software to enable these types of software needs requires intentional design to optimize testability. Software characteristics that are directly pertinent to System Testability include; abilities to perform Unit Tests, Customer Tests, Stress Test, Exception Tests, Failover Tests, Function Tests, Security Penetration Tests, Performance Test, System Integration Tests, Regression Tests, Code Coverage Tests, etc.

(R) System Reusability Factor. System Reusability is an important system quality attribute involves major architectural styles and patterns like the Service Layer Pattern [Fowler 2003], basic software design principles such as software encapsulation and the familiar SOA Tenets.

(P) System Performance Factor. System Performance often degrades System Agility and for this reason I've asserted that System Performance subtracts from the previously noted system quality attribute factors. Bummer. I wish that we could have our cake and eat it too but the reality is that when optimizing for System Agility, System Performance is a Tradeoff Point. For example, often the fastest systems tend to consolidate large amounts of logic, data and processing instructions onto a single platform to reduce network latency, packaging and unpackaging of inter-process information, data access, etc. I don't want to ignore performance enhancing techniques such as caching and patterns such as Data Transfer Object [Fowler 2003]. These are great ways to lessen the impact that System Performance can place on System Agility. It's just that these add a bit of complexity to the rest of the system and can degrade System Maintainability and System Testability for example and still don't, from a purist perspective, optimize System Performance.

(S) System Security Factor. Like System Performance, System Security often degrades System Agility and for this reason I've asserted that System Security has a negative relationship to the equation. For example, Adding software characteristics such as role-based security into a system at the data layer, application layer, host layer and network layer adds significant degradation to System Performance, System Testability and System Maintainability. I'm not at all suggesting that a Solution Architect should read this as a suggestion to place little System Security design into their system. The trick, as a colleague once told me, is to have just enough security.

System Quality Attribute Definitions

Agility

Agility is the ability of a system to be both flexible and undergo change rapidly. (MIT ESD 2001)

Flexibility

Flexibility is the ease with which a system or component can be modified for use in applications or environments other than those for which it was specifically designed. (Barbacci 1995)

Maintainability

Maintainability is:

· The aptitude of a system to undergo repair and evolution. (Barbacci 2003)

· The ease with which a software system or component can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment. (2) The ease with which a hardware system or component can be retained in, or restored to, a state in which it can perform its required functions. (IEEE Std. 610.12)

Interoperability

Interoperability is the ability of two or more systems or components to exchange information and to use the information that has been exchanged. (IEEE 1990)

Testability

Testability is the degree to which a system or component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met (IEEE 1990).

Reusability

Reusability is the degree to which a software module or other work product can be used in more than one computing program or software system. (IEEE 1990).

This is typically in the form reusing software that is an encapsulated unit of functionality.

Performance

Performance is the responsiveness of the system – the time required to respond to stimuli (events) or the number of events processed in some interval of time. Performance qualities are often expressed by the number of transactions per unit time or by the amount of time it takes to complete a transaction with the system. (Bass 1998)

Security

Security is a measure of the system’s ability to resist unauthorized attempts at usage and denial of service while still providing its services to legitimate users. Security is categorized in terms of the types of threats that might be made to the system. (Bass 1998)

Reliability

Reliability is the ability of the system to keep operating over time. Reliability is usually measured by mean time to failure. (Bass 1998)

Supportability

Supportability is the ease with which a software system is operationally maintained.

Performance

Performance is the responsiveness of the system – the time required to respond to stimuli (events) or the number of events processed in some interval of time. Performance qualities are often expressed by the number of transactions per unit time or by the amount of time it takes to complete a transaction with the system. (Bass 1998)

Security

Security is a measure of the system’s ability to resist unauthorized attempts at usage and denial of service while still providing its services to legitimate users. Security is categorized in terms of the types of threats that might be made to the system. (Bass 1998)

Scalability

Scalability is the ability to maintain or improve performance while system demand increases.

Usability

Usability is:

· The measure of a user’s ability to utilize a system effectively. (Clements 2002)

· The ease with which a user can learn to operate, prepare inputs for, and interpret outputs of a system or component. (IEEE Std. 610.12)

· A measure of how well users can take advantage of some system functionality. Usability is different from utility, a measure of whether that functionality does what is needed. (Barbacci 2003)

Sources

· [Bachmann 2000] Bachmann, F.; Bass, L.; Chastek, G.; Donohoe, P. & Peruzzi, F. The Architecture Based Design Method (CMU/SEI-2000-TR-001 ADA375851). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2000. Available WWW: <URL: http://www.sei.cmu.edu/publications/documents/00.reports/00tr001.html>.

· [Barbacci 1995] Barbacci, M.; Klien, M.; Longstaff, T; Weinstock, C. Quality Attributes - Technical Report CMU/SEI-95-TR-021 ESC-TR-95-021. Carnegie Mellon Software Engineering Institute, Pittsburgh, PA.

· [Barbacci 2003] Barbacci, M. Software Quality Attributes and Architecture Tradeoffs. Software Engineering Institute, Carnegie Mellon University. Pittsburgh, PA.

· [Bass 1998] Bass, L.; Clements, P.; & Kazman, R. Software Architecture in Practice. Reading, MA; Addison-Wesley.

· [Bass Kazmann 1999] Bass, L.; Clements, P.; & Kazman, R. Architecture-Based Development.

· [Fowler 2003] Martin Fowler. Patterns of Enterprise Application Architecture, Boston, MA. Addison-Wesley.

· [Gamma 1995] Gamma, E.; Helm, R; Johnson, R.; & Vlissides, J. Design Patterns, Elements of Reusable Object-Oriented Software. Addison-Wesley. Carnegie Mellon Software Engineering Institute

· [Hohpe Woolf 2004] Gregor Hohpe and Bobby Woolf. Enterprise Integration Patterns. Boston, MA. Addison-Wesley.

· [IEEE 1990] Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY.

· [IEEE 1992] IEEE Std 1061-1992: IEEE Standard for a Software Quality Metrics Methodology. Los Alamitos, CA: IEEE Computer Society Press.

· [Kazman 2000] Kazman, R.; Klein, M. & Clements, P. ATAM: Method for Architecture Evaluation CMU/SEI-2000-TR-004 ADA382629. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University. Available WWW: <URL: http://www.sei.cmu.edu/publications/documents/00.reports/00tr004.html>

· [MIT ESD 2001] Tom Allen, Don McGowan, Joel Moses, Chris Magee, Dan Hastings, Fred Moavenzadeh, Seth Lloyd, Debbie Nightingale, John Little, Dan Roos, Dan Whitney. ESD Terms and Definitions (Version 12); Massachusetts Institute of Technology. Engineering Systems Division. ESD-WP-2002-01, October.

Enterprise Architect vs Solution Architect

What exactly is an Enterprise Architect versus a Solution Architect? I'd like to chat about the difference because I'm not confident everyone understands this well.

It's actually quite simple. I propose that a Solution Architect is a project team role that is responsible for the system quality of the solution being delivered to the business. I also propose that an Enterprise Architect is a planning role that is responsible for identifying the future state of an organization's IT environment and engage wherever and whomever necessary to help guide project team's to deliver toward it. There are formal definitions out there but I thought I'd simplify it for the purposes of this blog post.

I get the impression there are people out there that think an Enterprise Architect is a Solution Architect but work in enterprise organizations. I also have the impression that there are people out there that think an Enterprise Architect is someone who only works with Powerpoint, collects information from Solution Architects and spends the majority of their time with the business leads and governance boards merely reporting on the information they've pulled together. Although I recognize that there are organizations in situations that implement Enterprise Architect and Solution Architect like this, I beleive they are inneficient and are likely in a transition state to the more efficient role definitions I proposed earlier.

Taking my proposed definitions, I'd like to identify architect subtypes to help support the difference between them to help describe what I'm talking about.

A Solution Architect may have a number of different types of architects working for him/her to help accomplish their task for delivering a high quality solution. For example, s/he might have an Infrastructure Architect to manage the architecture of the solution's hardware configuration so that the solution meets the Quality of Service business and IT requirements while at the same time represents the optimum way to deploy the solution into the target production environments.

There also might be a need for 'specialist' architects depending on the complexities of the business requirements or the target production environment. Such 'specialist' architects usually are called Domain Architects and examples include; Security Architect, Technology Architect (ie architects that specialize in a specific product or technology), Vertical Architects (ie architects that specialize in systems that are specialized in particular industry verticals such as Financial Services Industry, Telecommunicaitons, Public Sector, etc).

An Enterprise Architect may have also have a number of different types of architects in order to piece together a coherent, actionable future state architecture which can easily map to business strategy, be consumed by project teams and be a major contribution in governance activities.

For example, an Enterprise Architect may have Business Architects which document Business Strategies, Business Capabilities, Business Processes and Roles as well as a number of other artifacts to help analyze them such as mapping artifacts (see here).

An Enterprise Architect may also have Information Architects who document the information models such as Data Subject Areas, Data Facets, Business Objects, Business Entities and Data Entities with the intention of supporting the Business Processes while at the same time desiging for data integrity and data quality for the enterprise.

An Enterprise Architect may also have Infrastructure Architects (aka Technology Architects) that focus on the hardware and operating system-level infrastructure.

Lastly, an Enterprise Architect may also have Solution Architects (aka Enterprise Solution Architects and Enterprise Application Architects) who focus on pulling all of the other Enterprise Architecture information together to shape the future state application system architecture.

Here is one place where I think there is confusion by many. You see, I described a Solution Architect at the project-level and an Enterprise Solution Architect across the enterprise and both share the words 'Solution Architect' in their role. They have VERY different purposes but are very complimentary. Could it be that simple of a reason why confustion exists? It just might be.

An Enterprise Solution Architect and project Solution Architect roles are very complimentary and because this relationship is of particular interest to me I'd like to take a moment and propose how they are to work together.

 I propose that the Enterprise Solution Architect be involved at the earliest point a new business initiative is created and do very high-level 'solutioning' via whiteboard and reference to future state architecture elements. Then, when the business initiative gains momentum is backed by Enterprise Architecture future state analysis the core project team is formed and the project Solution Architect takes over to be responsible for the solution. The Enterprise Solution Architect becomes a member of the project Solution Architects team and is responsible for the system integration architecture where the solution requires integration between enterprise systems as well as be responsible to provide future state system architecture guidance to help the project Solution Architect make decisions on which systems to commit to using in the solution. The Enterprise Solution Architect then is involved in governance boards to inform decision-makers with future-state architecture artifacts to help justify major technology, system, or business value decisions. Thats it.

As a quick summary, project Solution Architects and Enterprise Architects are different in that they have very different purposes. They are highly complimentary in that Solution Architects focus on delivery of solutions and Enterprise Architects focus on supporting them by documenting future state, participating on their teams and being involved in governance activities.

Skills from different experiences - Well rounded is King

I currently sit in Microsoft IT and get to share experiences and learn with some of the most interesting folks in the world. My role encourages me to generate good ideas for the company and work with others through natural alignment to build great products for Microsoft. This is good fun.

I'm recently noticing more and more that the soft skills that I've picked up during my career are invaluable to be successful. And for this reason, I've personally begun a journey to strengthen my leadership abilities. One method I use is to look introspectively at myself to discover strenghts to leverage and weaknesses to manage. As a byproduct, I also do a bit of analysis of others around me to find their strengths to leverage and weaknesses to manage. This is what has brought me to this blog entry on the need for well-rounded skills.

My consulting experience: When I was an IT consultant playing roles such as Sollution Architect, Devleopment Lead and Program Lead I was measured on delivering IT solutions to customers that were of highly successful (ie on-time, on-budget, meeting customers satisfaction and of high system quality). In that environment, I learned that it was essential to pick up skills to survive because I was surrounded with folk that had brilliant customer-facing, fast-learning, quality-focused, and most of all strong professionalism skills. You had to have these skills to be successful.

My sales experience: When I was seconded to a sales team for a while as a Enterprise Solution Architect playing roles such as pre-sales technical architect, pre-sales strategist and partner strategy consultant I was measured on driving programs which lead to increased revenue and partner satisfaction. In that environment, I was surrounded with fast-talkers, extremely confident and capable sales resources - I'm not talking the sort that do more adminstrative sales but those few, rare breeds that have mastered the art of executive sales for large enterprise customers.

My IT experience: Over my cumulative IT experience, I have played roles such as Developer, Developer Lead, Test Lead, Program Manager, Solution Architect and Enterprise Architect. All of these roles generally are about delivering solutions to the business. I've been surrounded with individuals who have extensive engineering knowledge and great solution delivery skills. These are essential to be successful delivering IT solutions to the business.

Ok, now the interesting part of this blog. Having a varied background in roles ranging from sales to consulting to IT have really helped me make greater impact. Skills that were a prerequisite for success in one environment are a bonus in another. For example, in IT, skills that I developed while in sales roles that helped me build trust with partners becomes a bonus for learning how to build trust with like-minded groups in IT. And as a result, together we achieve greater impact that is relatively unusual. We acheive a sort of 1+1=3 situation. This is not all that common in IT shops but is normal in sales and consulting.

Let me dive a bit deeper to explain. The stereotypical sales role will require to peice together bits and bobs of products a and b, then peice together a partnership with hardwar vendor x, software vendor y and delivery partner z all within a matter of days. The skills necessary to do this are either there are aren't and if they aren't, you are not as successful a salesperson or presales consultant as one could.

The stereotypical IT roles will require to think long and hard about a software system and then snap to a relatively well-defined team model in a well-defined process model as part of a software development lifecycle for example.

Therefore, one might argue that there are skills developed in a sales environment that could prove useful to other environments such as IT. As products of our environment, we naturally develop the survival skills our environment requires. If we have a relatively well-rounded experience, we have relatively more skills to bring to the table that will allow us to make bigger impact.

Perhaps, if we made deliberate movements to be in positions of different environments and while there carefully nurtured and honed to excellence the necessary skills to survive in those environments we would be all that more effective. I think that this is an interesting opportunity for all of us.

How SaaS, S+S impact an Enterprise Architect

Mike Walker wrote a great thought-provoking blog post on the implications SaaS has on Enterprise Architecture. Although he noted some very interesting points, I thought I’d extend this a bit and describe the impact of my life as it pertains to SaaS because coincidentally, I'm an Enterprise Architect and am personally tasked in an initiative to help solve how Microsoft IT is involved with SaaS. So, I'm in the throes of the interesting implications of how I do my job as I address this challenge.

I posted some of the thoughts on how I address business analysis as part of defining the Business Architecture. I break up the problem space into two very different areas: Business Analysis for Consuming SaaS and Business Analysis for Providing SaaS. Here are the blogs respectively.

· http://blogs.msdn.com/gabriel_morgan/archive/2007/07/18/business-analysis-for-consuming-saas-services.aspx

· http://blogs.msdn.com/gabriel_morgan/archive/2007/07/18/business-analysis-for-providing-saas-services.aspx

Because I'm short on time let me blurt out some comments in the area of "EA implications for consuming SaaS software":

• The distinction between business capability and applications is very important. This will get clearer as I describe the Business Architecture implications below. Btw, I wrote a blog about these concepts to put them in an information model view to help describe how they relate. See here http://blogs.msdn.com/gabriel_morgan/archive/2007/07/31/traceability-from-biz-strategy-to-application.aspx.
• Application Portfolio Management is still in the picture. Although the SaaS service means that the software and infrastructure is in the cloud, they are still a part of our application portfolio and must be rationalized to avoid redundancy and managed to ensure we make informed decisions how to position it over time.
• With regard to the Business Architecture domain, things get interesting with consuming SaaS services because:
• There needs to be attention paid on consuming SaaS services which are ‘Supporting’ business capabilities rather than focusing on those business capabilities which are ‘Core’ to a business. Why only the Supporting business capabilities? Well, because we don’t want to be locked into the dangers of our businesses struggling to be innovative and agile with their business process and them being constrained by a SaaS software that automate them. Remember, that the majority of SaaS provider software out there is built to be supported by several companies simultaneously using the same code base.
• There needs to be attention paid to the 'connectdness' of business capabilities and look for business capabilities that are relatively independent of one another. That is, look for business capabilities that have relatively little dependency on other business capabilities especially as it pertains to business process and information.
• Business process integration. We need to still model the SaaS software in relation to business processes to ensure we are optimizing the value of the SaaS software investment.
• With regard to System Architecture domain, things get interesting:
• When desigin system integration for both business process workflows as well as the data integration needs via system-to-system data integration. There are some interesting innovations happening in this space as system and data integration themselves can be SaaS services but I digress. Anyway, think of the challenges of supporting systems in your local IT shop that must, and I repeat, must integrate with services in the cloud. Such challenges and being responsible for the Quality of Services requirements your business has as it relates to their system, which they may not even be aware depends on clous services, such as system reliability, system maintainability, system supportability, and system testability. Yes, these issues fall on the shoulders of the local IT shop and they are not simple to solve. In our experience, which is quite young, requires an astonishing close relationship with our SaaS providers to the point that sometimes it looks like they are merely an extension of our IT shop. I'm sure that this will change as SaaS providers and the consumers (aka us) work out the kinks of working better together and streamline the basic delivery activities but for now, we are still learning.
• Presentation mash-ups. As an EA, we love the concept of the business being able to build their own applications using readily available software services via presenation applications and workflows. Nick wrote more about this on this blog entry so I won't cover it here. The point I want to make is that we promote those SaaS services which enable this type of situation.
• With regard to Information Architecture domain:
• Like Mike noted, attention must be paid to the information that can legally be stored in the cloud. Think financial information in Europe. This is not always legal for this type of information to leave the country.
• Data integration needs are very important. We are very weary of storing data in the cloud if we have Quality of Service requirements such as Data Staleness of less than 1 hour (or thereabouts). This is just an observation and probably a result of a lack of maturity of system integration abilities and think that we will overcome this in due time.
• Data Masters are left on-premise at the moment. We are very weary of storing master data outside of our control. In fact, I'm not aware of any such situation. Instead, I'm seeing more interest in SaaS software that stores anciliary or extended information that is readily retrievable to a master data store.

In short, SaaS provides a lot of potential cost savings that are of high interest BUT they do bring with them some interesting challenges to an Enterprise Architect to make sure that SaaS sofware is optimized for the business investment.