Gabriel Morgan

As mentioned in a previous post, I announced that our Enterprise Architecture team has made some very interesting investments in the area of Strategy Management and Portfolio Management in the last year via an Enterprise Architecture offering called “Strategy and Planning Service”. It’s very interesting and we’ve gathered enough experience through our mistakes and successes that I think I’m ready to share more on it to the broader community to help others. Keep in mind that we are relatively new to this area and learning more every day so I might change my opinion on some things. Here’s what I currently think.

As a bit of background, our investment in Strategy Management and Portfolio Planning is a result of our team’s need to understand Microsoft’s business strategy and connect it to changes in our enterprise architecture to inform project portfolio managers to fund the right projects and include the right scope in the funded projects. The result is an accelerated change in our architecture streamlined to achieve our corporate strategy.

We’ve decided to provide an offering from Enterprise Architecture team that essentially is a template to implement an Office of Strategy Management concept at particular areas in our enterprise. The template heavily leverages Kaplan and Norton’s Office of Strategy Management concept but is enhanced to include bits to support Strategy Formulation and Portfolio Optimization to bring an end-to-end offering for Strategy Management and Portfolio Management – one without the other is a waste of time in my opinion. We also embedded into the offering concepts to help derive platform strategy and other important Enterprise Architecture concerns like Strategy Formulation, Business Model, Operating Model, Core and Context Processes, etc. Anyway, I wanted to share with you some important details we’ve learned so far:

1. Be able to model business strategy to span the enterprise. It’s common practice to consider business strategy as scoped to a particular revenue-generating business (for not-for-profit businesses, the scope of a business strategy is often the ‘services’ they offer.) This is an awfully narrow portion of any enterprise because it doesn’t include operational businesses like Finance, HR, Sales, Support and IT. For example, Microsoft Office has a business strategy but IT wouldn’t according to common practice. With a couple of tweaks to the discipline of documenting a Business Strategy as well as make the assumption a Business is equivalent to an organization responsible for a P&L, we can connect all organizations to a cascaded business strategy that spans all organizations in an enterprise. Of course, there are several methods out there to do this. We have chosen Balanced Scorecard as a format to capture a business’ strategy in my group for a number of factors. I don’t presume this is the right choice for everyone. Anyway, using the Balanced Scorecard, we’ve implemented a process discipline of connecting Business Objectives in the Customer Perspective to a supporting organization’s Stakeholder Perspective’s Business Objectives, we get a natural cascade model that connects organization’s business strategy together. This is a rule of thumb to start with – it doesn’t always work. We sometimes have to apply some human review to modify a child’s business strategy to make it more complete while always keeping an association to the parent Business Strategy as a matter of principle.
2. Provide value-add support to Portfolio Planning to gain adoption. In order to be involved in the planning process, Enterprise Architects need to come with some sort of value proposition. We’ve built a data model to help provide the following value propositions to our planning process:
   • Data Quality. We provide quality data to the planning process facilitators that offers the following value propositions:
     • Strategy gaps, overlaps, dependencies and conflicts. This is my favorite value proposition because it was fun to formulate the data model to deliver on the promise. I also like it because having the ability to maturing strategy to the point where we can manage across the enterprise is a direct hit to being able to drive the necessary changes in our enterprise architecture to accelerate the company’s ability to deliver on strategy.
     • Providing a system with an implicit data model that forces data-entry to be consistent and of high-quality. This is important to those who are responsible for quality of the information managed in the planning process. For example, we can monitor the completeness of a Balanced Scorecard to ensure Goals exist with Objectives for all Perspectives.
   • Portfolio Prioritization. We provide guidance how portfolio managers can identify criteria to prioritize their portfolios. Essentially it’s advice how to choose business objectives from the business strategies,  how to weight them, how to associate new program demand to weighted criteria, how to analyze the results and compare against industry benchmarks, and, most interestingly, how to evaluate the prioritization criteria to effectively represent the charter of the portfolio itself.
   • Portfolio Optimization. We provide enterprise architecture analysis to look for possible portfolio optimizations such as;
     • Roadmap alignment. this is where traditional enterprise architecture work is leveraged. That is, many enterprise architecture teams develop plans for how to build out platforms, competencies, capabilities, processes, etc. Assuming those roadmaps are ‘effective’, we plug them into the planning process’s optimization activities. This is one simple way of gaining adoption of these types of enterprise architecture deliverables.
     • Strategy alignment proof through traceability of Programs to business objectives of the various business strategies.
     • Program rationalization through redundancies discovered via common processes being produced by different Programs.
     • Program dependency analysis based on shared application, platform and information to help ensure we fund all dependent Programs for other priority Programs.
     • Reuse of standard applications and platforms to ensure are in scope for programs to avoid building redundant apps and plats.
     • Possible organization adoption for program building solutions that might be useful by other organizations not currently in scope.

One really important note is that we heavily rely on our information model to deliver the above points. Getting this right is the secret sauce, the science if you will, to delivering on the above value propositions.

I’d like to tell you more about the Strategy Management and Portfolio Planning architecture work we are doing such as our Organizational Alignment, Team Model, Process Model, EA reference models, multitude of business concepts, etc but I’m not entirely confident we’ve cracked the nut on them just yet. Sharing what we have today may cause more confusion than value so I’ll wait until they are a bit more refined before sharing.

I’ve come to some interesting conclusions regarding Roadmaps that I thought might be interesting to others. About two years ago, I was given responsibility on behalf of the Enterprise Architecture team to provide Roadmaps on behalf of MSFT’…

It’s time to rethink enterprise architecture people. Well, at least here in Microsoft IT’s Enterprise Architecture Team it is.

Like most EA teams, we’ve had our ups and downs and experiences leveraging various Enterprise Architecture Frameworks, methods, disciplines, etc. Like you, over the years we’ve learned what works and what to avoid.

For the past year or so, I’ve led a crack team of experts focused on aligning IT and the Business, and from this journey I wanted to share with you my current thinking. My team is called Enterprise Strategic Planning and it is a service team dedicated to enterprise-wide strategy and planning. Our initial goal is to become critical to the planning process with the intention of providing data to qualify an optimal set of IT Programs to invest in. This is quite interesting and we leverage concepts like an Enterprise Information Model for traceability all the way from Strategy to Application to Device and Location, enterprise roadmaps to describe a Business’ business capability maturity over time through Program investment, Application Roadmaps to describe an Application’s trajectory, Platform Roadmaps to describe where and when we have reusable software, etc. I can talk all day about the ESP Service team and how we do it, but in this article I wanted to share with you something that has occurred to us during our journey and describe some changes we are making that I think is ground-breaking in the Enterprise Architecture domain.

Assuming a primary goal of EA is to align IT to the Business, the problem is that most, if not all, EA Frameworks are not equipped to actually deliver on this goal. They are limited to drawing associations from IT things (eg IT Projects, Applications, Platforms, IT People/Role, Infrastructure) to Business things (eg Business Initiatives, Business Goals, Business Capabilities, Business Processes, and Operating Models). Some of the more mature EA teams have partnered with their finance department to apply financial modeling (eg Business Value Realization, Return on Investment, Net Present Value) to these associations to help describe business value in monetary terms and possibly start a chargeback model. These are all great accomplishments but at best they only capture how IT ‘relates’ to the Business. That is, these EA Frameworks and methods are more about IT transparency, not alignment.

‘Relating’ IT to the business is a problem because it is a game of catch-up. As the business changes, traditional EA approaches help IT execute through alignment techniques.The problem is that businesses are changing more rapidly every day, and IT is getting slower every day. Unfortunately, no amount of ‘relating’ IT to the business will actually bring better alignment.

Here’s the rub, have any of you out there noticed that business initiative cycles are getting smaller and IT project cycles are getting longer? How about this situation where the businesses we support have gaps in their ability to execute a strategy, or my personal favorite, where there are two or more business strategies that actually conflict with each other? How about the situation where businesses independently update their strategy? I’ve jotted down a long list of problems that need I’ve observed from time to time needing resolution in order to deliver IT alignment to the business.

Strategy out of sync with our supported Businesses:

1. Business Strategy in many businesses is not clearly defined using a common model for assessment
2. Businesses sometimes define strategy in near-isolation resulting in gaps, overlaps and sometimes conflicts
3. Business strategy changes on market demand while IT planning cycles occur yearly
4. Business interaction with IT is primarily limited to program execution details
5. Business lose sight and control of IT initiatives

Several Portfolios managed independently:

1. Several planning units in IT independently working in silos
2. Competing forces pulling the Applications and Platforms in different directions
3. Duplicate demand requests spread across multiple funding bodies
4. Gaps exist in our portfolio due to:
   • Inconsistent Prioritization Approach
   • Inconsistent Scope Management
5. IT Program Portfolio not directly associated to Business Program Portfolio
6. Lack of portfolio planning, value definition, and value realization
7. Portfolios out of date and do not reflect execution changes
8. Value is defined in high level business case but never locked down for measurement or final realization

I’m going to guess that I’m not alone here with these observations. I think these trends suggest IT is drifting farther from the business. And, to make things a little more scary, cloud computing allows the Businesses to on-board possibly VERY inappropriate enterprise software in a matter of minutes, things are going to get worse.

So, with this realization, my team has started to rethink the EA goal of aligning IT with the business. We’ve decided on a directional change to move from IT Planning in the context of the Business that require traditional EA Frameworks and methods that limit to ‘relate’ IT to the business, and instead focus on company transformation. The thinking here is to assist the company deliver on strategic goals, and of course provide traceability to IT investments, and shape IT to support the company deliver on our strategic goals. In a sense, IT planning is a byproduct of the company’s transformation.

We’ve begun to adopt business management concepts in an attempt to build a stronger understanding of how businesses are managed and incorporate them into our EA methods and tools. What’s really interesting is that there are proven best practices from business management groups to reuse. The trick for us is to ramp-up on these and adopt when we all have fairly IT backgrounds. As an indication of this commitment, we’ve recently  hired business strategy management and business initiative portfolio management subject matter experts to augment the team for this very purpose. Here are a few that we’ve begun to incorporate for example (Note, there are lots of methods to choose from – these just represent a subset that are appealing for implementation in our environment):

Michael Porter’s 5 Forces plus + Brandenburger and Nalebuff’s Sixth Force (Complementors)
Kaplan and Norton’s Office of Strategy Management and Balanced Scorecard
Alex Osterwalder’s Business Model
Geoffrey Moore’s “Core versus Context”

We’ve recently drafted a new Vision Statement, remember it is draft, and it goes something like “To Accelerate the transformation of IT, IT’s Relationship with the business and the business’ position in the market”. Two really important characteristics of the Vision Statement: 1) The word “accelerate” to imply we are a catalyst function and offer value through services to help the company achieve our strategic goals and 2) It has a destination of “business’ position in the market”. We feel that we have not fulfilled our vision until our company’s corporate-wide strategy is met.

An important note is that EA doesn’t have to own all of the new business functions that may be required in your organization in order to ‘accelerate the transformation of the company’. I would say, however, that EA should be responsible for justifying the existence of them and help establish them where they exist. For example, in our organization, we are in the process of establishing a team that will function similarly to Kaplan and Norton’s Office of Strategy Management. We took the initiative to educate the organization on the purpose and need for existence, then helped find the rightful owner and gain their commitment to implement it. EA merely has a seat at the team’s table to do our part in the new function, which usually requires us to deliver consistent models across the company for impact analysis. Unfortunately, only through experience can an EA team know which organizational functions (eg E/PMO, Finance, Change Management, Office of Strategy Management, Business Initiative Portfolio Management) need to exist and when in order to deliver on the goal of business transformation. We have yet to find a source of material that supplants sheer experience.

Adopting Strategy Management and Portfolio Management into your Enterprise Architecture function, coupled with the onus for an EA team to help the organizations build organizational functions that need to exist to deliver on enterprise-wide transformation is the breakthrough I wanted to share. I think that today’s EA Frameworks and methods don’t include these two aspects and they are limited to delivering IT transparency/relating IT to the business, which is good but not good enough to align IT to the Business.

And interestingly, we feel that a shift in  EA’s focus to ‘company transformation’ instead of ‘IT planning to align with the business’ results in the planning of IT as a sort of byproduct as it is a natural outcome transforming the company.

Although we are still learning, I’m getting really excited about this change in Enterprise Architecture. I’ll keep you updated to share with you our learning as we go on this journey.

I have the fortunate opportunity to manage the Enterprise Platform portfolio for Microsoft IT and thought that I’d share some tidbits how I do it.

In Microsoft IT, the Enterprise Platform Portfolio (EPP) is only one program portfolio peer to other program portfolios like our Line-of-Business (LoB) specific portfolios such as Sales, Marketing, Services, HR, Legal, IT (yes, even IT is a LoB to us), etc. The EPP is a portfolio designed to manage our platform systems and encourage them to deliver more value to the company.

I’ve distilled the EPP’s Charter (aka Team Model, Process Model and Delivery Approach) into the following points to help articulate how I manage the EPP:

1. Fund Platforms only. It seems simple enough, but defining what is a Platform and what isn’t like Application, Vendor Products, Processes, Capabilities, Locations, etc can be a bit tricky. We pulled our definitions from our Enterprise Information Model and elaborated on them to help communicate what qualifies for funding from the EPP and what doesn’t. We use a couple of views, one that is more loose and one more explicit to help communicate to different audiences. Here are a couple of diagrams that we use:

   Architecturally-pure Platform Diagram	Exec-ready Platform Diagram

   • An Enterprise Platform is a set of Components where one or more of those Components are used by more than one Application. More than one Line of Business uses these Applications.

   • An Enterprise Platform may master a Data Facet.

2. Fund non-discretionary costs first, then allocate the remaining budget based on criteria intentionally used for the Platform to deliver business value. Here is our prioritization criteria as a reference:

   Business Alignment
   	Relation to Goal Prioritization	Does the Platform relate to highest priority Business Goals?
   	Capability Assessment	Does the Platform relate to priority Business Capabilities Assessment (Value, Performance and Maturity)
   	Business on-boarding Commitment	Can the Platform demonstrate commitment from multiple businesses?
   Portfolio Simplification
   	# of Redundant Apps and Plats	• Will the Platform reduce redundant Applications/Platforms? • Will the Platform retire similar functioning Applications/Platforms slated for retirement?
   	Retirement of Unsupported Vendor Products	Will the Platform retire the use of unsupported vendor products?
   Platform Excellence
   	Information Quality	Will the Platform improve information quality; make information more accurate and available?
   	Regulatory Compliance	Will the Platform help Microsoft comply with Regulatory Compliance?
   	Security and Privacy Policy Alignment	Does the Platform comply with Security and Privacy Policies?
   	Agility	Flexibility, Maintainability • Flexibility to support many Business Processes • Self-service

3. Solicit senior Architects to form a role-based Team Model. I’ve created a Team Model with 5 voting members filled by Microsoft IT’s most senior Architects. Each advocate 5 different perspectives of our Platforms investments; Business Advocate, Enterprise Architecture Advocate, Technology Use and Incubation Advocate, Platform Software Quality Advocate, Operations Advocate. It’s important not to make this team model reflective of the organizational team model but rather a set of perspectives of a platform. This avoids the situation of having organizational-bias in the voting and commentary of Programs in the Portfolio.
4. Platform Roadmaps. We use Platform Roadmaps to document what the Platform will do. The entities on a Platform Roadmap mirror the information in our Prioritization Criteria. That is, a Platform Roadmap includes all associated Business Goals related to the Program affecting the Platform, Business Capabilities and Process Flows improved, Applications and Platforms that will be retired as a result of the Platform, supporting Vendor Products, etc. We equate Platform Roadmaps to a sort of contract or agreement that the Program must adhere to. During the Program’s delivery, we run current Program information and compare it to the Roadmap to determine we the Program is on-plan or not. From the EPP’s perspective, the Platform Roadmap is the scope of the Program.
5. Enterprise Architecture to manage the EPP. Managing the EPP is the responsibility of our Enterprise Architecture team. This is important because the Platforms are an enterprise concern and require skills plus organization position to perform the necessary analysis to optimize our platform portfolio. For example, we perform analysis to form our Platform Strategy that includes cross-LoB needs analysis, associations to our enterprise data facets, application and platform consolidation methods, vendor products analysis to optimize our licensing and support contracts. Also, being positioned outside of the typical IT value chain (LoB-facing resources, engineering/development, and support) allows us to easily traverse the organization and remove organizational bias.
6. Data-driven funding allocation process flow to balance the portfolio. I’ve put together a relatively simple funding allocation process flow which allocates funding to Programs via decision points. For example, if a Program is in-flight, we allocate funds to ensure its original scope is delivered. If a Program requires funding to become compliant, we allocate compliance funds. One thing that we do to help spread the funds so that we don’t find ourselves shoveling all our available funds into one or two programs is utilize the concept of ‘seed’ funding. Seed funding is a limited amount of funds to allow a team to prove themselves per our Prioritization Criteria listed above. In our situation, we have some platforms that veer off-plan, therefore, score low on our Prioritization Criteria. In these situations, we limit funding to simply allocating non-discretionary funding and then seed fund them to get them back on track. This allows us to spread the funds further and fund new Programs and course-correct existing Platforms. Our customers perceive this as IT being more agile to changing business needs. For our funding allocation process flow to work, we must make the decisions data-driven to remove opinion and bias as much as possible. This is where my senior architects come into play. That is, they vote Y/N on each Prioritization Criteria for each Program. Those that rank higher are pushed through the funding allocation process first. We iterate through the funding allocation process flow until all available budget is allocated. Then draw the line leaving us with a list of which Programs are funded, what scope is being funded.
7. Continuously invest in Portfolio Management maturity. There are always improvements to ensure the platform portfolio is managed to deliver the most business value possible. The more mature the portfolio management, the more business value realized. Capabilities such as:
   • Portfolio Optimization in terms of
     • Program Dependency Analysis to understand when Programs can be hydrated to optimize resource allocation.
     • Program Overlaps and suggestions for what should happen to them.
     • Platform Strategy to understand where we want Platforms to go directionally and how to get there via promotion of Applications, retirement of Applications and Platforms, etc
     • Program Gaps to be filled as a results of analysis of Business Strategy
   • Strengthening the Portfolio Management Team to sit on funded Program Teams to guide and ensure delivery to stated Platform Roadmaps
   • General continuous improvement

I’m curious to learn what others do to manage platforms. Please share your thoughts if you have a moment.

I’ve been fortunate to be in a position as a trusted advisor assess individuals during performance reviews as well as to hiring managers internal and external to Microsoft looking for strong architect candidates. For the most part, a lot of my ju…

I recently had the opportunity to share an idea with a group of enterprise-level Architects and received a healthy bit of positive feedback on the idea. So, I think its worthy to share more broadly.

Most, if not all, Enterprise Architects have witnessed challenges delivering a successful Enterprise Architecture Team. I certainly have observed failings and I’ve been involved in failures directly. My Enterprise Architecture team has tried something a bit different that seems to be working and I’d like to share it with you.

The basic premise is that traditional Enterprise Architecture teams tend to lean toward delivering things like:

• Conceptual Information Models
• ‘Stick’ Governance Models
• Principles and Standards
• Position Whitepapers
• Architecture Review Board Sessions
• Consultative-only advice

While all of these are nice to have, by themselves I believe they lead to the Ivory Tower. It’s no wonder why Enterprise Architecture teams that only do the above also tend to have the following challenges:

• Struggle to prove valuable
• Struggle to be influential
• Struggle to be relevant
• Struggle to be enterprise-wide

About a year ago, my team was engaged on an enterprise problem commonly known as Enterprise Strategic Planning, which for us was about addressing three CIO concerns for the purpose of portfolio management/funding allocation of project dollars. The portfolio managers need to know:

1. IT and Business Alignment
2. Gaps and Overlaps
3. Technology Investments

At this point, we could have participated to support the Enterprise Strategic Planning effort by delivering things noted above as a traditional Enterprise Architecture would. Instead, we decided to take a different approach. We decided to adopt the Service Provider business model equipped with Service Offerings. We call it Enterprise Strategic Planning (ESP) Service and our Service Offerings include; ESP Collaborative Process, Roadmaps, Analysis, IT Proposals, Standards Alignment, and Enterprise Model/Taxonomy Maintenance. All of these are geared to delivering direct value to IT organization’s planning needs.

Mind you, we use Conceptual Information Models, principles and standards, etc but this is primarily behind the scenes and they often don’t surface in discussion unless one of our stakeholders asks a probing question of our service offerings. This is important, I’m not suggesting to ignore delivering traditional EA artifacts like CIM, position whitepapers, etc. We deliberately use them to ensure our offerings are of high quality and fidelity. High quality and fidelity are important characteristics of our brand we must manage carefully.

The paradigm shift is moving from a traditional Enterprise Architecture team to a Service Provider. We manage the ESP Service as a product line with offerings, we have a business plan, we have a strategy, we have a market with competition, we have a balanced scorecard to monitor our success to our strategy…just like any well-managed business.

A couple of interesting outcomes that are largely due to this shift:

• We no longer have the challenges mentioned above. We deliver value with explicit associations to enterprise problems. We are more influential than ever because we have voting-rights on enterprise decisions, We are highly relevant to important decisions as evident by our engagement with our company’s top brass. We are only engaged on enterprise-level problem areas.
• I don’t have the additional problem of having to sell Enterprise Architects. Previously, I would have to take time to explain how an Enterprise Information/Business/Infrastructure Architect is relevant to problems and decision making. Now, I simply deliver an offering that is required for a decision affecting our enterprise to occur. I hire Enterprise Information/Business/Infrastructure Architects to deliver the offering.
• I don’t have to ask to be influential. Our offerings are a requirement. Our deliverables are not an option. Because they implicitly have our thinking built-in, they influence our organization implicitly without having to spend a tremendous amount of effort winning relationships. Btw, I’m not saying we don’t require unbelievably strong relationship skills (aka emotional intelligence), we do.

My suggestion to you all is “Don’t build Enterprise Architecture teams/functions to have Architecture. Instead, solve enterprise problems with Enterprise Architects.”

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.

 

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:

Term	Definition	Source
Competitive Business Strategy (aka Business strategy)	Business Strategy refers to how a company competes in a particular business (note: overall strategy for diversified firms is referred to as corporate strategy). Competitive strategy is concerned with how a company can gain a competitive advantage through a distinctive way of competing. Competitive Business Strategy refers to the aggregated strategies of single business firm or a business unit that incorporates either cost leadership, differentiation or focus in order to achieve a sustainable competitive advantage and long-term success in its chosen arenas or industries. The essence of strategy is choosing a unique and valuable position rooted in systems of activities that are much more difficult to match.	Michael Porter, Harvard Business School
Business Process	A business process is a collection of related, structured activities or tasks that produce a specific service or product (serve a particular goal) for a particular customer or customers. It often can be visualized with a flowchart as a sequence of activities.	Harvard Business School
	A business process is a series of interrelated activities that convert inputs into results (outputs); processes consume resources and require standards for repeatable performance; processes respond to control systems that direct the quality, rate, and cost of performance.	APQC
Business Process Categorization	A reference framework for categorizing all the business activities used by an enterprise involved in delivering products and services. This is done through the definition of each area of business activity, in the form of process components or Process Elements that can be decomposed to expose progressive detail. These process elements can then be positioned within a model to show organizational, functional and other relationships, and can be combined within process flows that trace activity paths through the business. Business Process Categorization can serve as the blueprint for standardizing and categorizing business activities (or process elements) that will help set direction.	TMForum.org
Business Software Platform	Standardized business software engineered for reuse. Often Business Software Platforms are responsible for mechanizing standard business processes and managing standard data. Note: I couldn’t easily find a non-bias definition so I researched and aggregated definitions from several credible sources, then simplified to avoid too much criticism while maintaining the sources intent.	Gabriel Morgan 🙂

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.

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.