EA and Lean Six Sigma

I recently became Lean Six Sigma (LSS) White Belt certified through my current employer.  My company’s intention is to white belt certify all employees while continuing with more advanced certifications for management.  The question this raises with me, and a question that has been raised by many others, is how does an LSS initiative align with an EA initiative?

My take is that they are complimentary, but one does not fully embody the other and they both should operate independently.  I think it is extremely healthy for LSS principles to permeate the EA Team and be part of the team’s culture (as it should be for the entire enterprise), however, that doesn’t mean the EA Team can, or should own the application and promotion of LSS throughout the enterprise.

LSS is defined as a set of process improvement tools for reducing waste associated with the flow of materials and information in a process (moresteam.com, n.d.).  Enterprise Architecture, as my EA Foundations I class at Penn State taught me, is defined as the process of translating business vision and strategy in effective enterprise change.  The scope of each is very different; process improvement versus strategic planning.  

Another way of highlighting the distinction is this; LSS is focused on optimizing the current-state, while EA is focused on defining the future-state.  With such different scopes and objectives, it seems clear that they are separate initiatives, and one should not own the other.  With that said, there should certainly be plenty of joint planning, participation, and knowledge sharing.  An LSS initiative will benefit by having knowledge of the future-state and enterprise-level changes that are forthcoming, while EA will benefit from a culture of “lean” and from the business knowledge obtained by LSS process improvement efforts.

One final point.  My posting thus far assumes that there is a central LSS team that is training, mentoring, and leading the charge for process improvements throughout the enterprise.  This may be the typical model for most enterprises when they first adopt LSS, however, it does not have to remain that way.  Once an enterprise matures its LSS capabilities to the point it permeates the entire enterprise and is truly embedded into the culture, it is possible to disband the centralized LSS team.  One of LSS’ strongest proponents, Xerox, recently did just that, as the following excerpt from the Democrat & Chronicle states (Daneman, 2014).  

In a memo to employees earlier this month, president of corporate operations Herve Tessler said that Xerox, having met its goal of “embedding the principles and practices of (Lean Six Sigma) within the business ... we no longer have a need for a centralized LSS function and (will) disband the corporate LSS team.”

My final thoughts on EA and LSS can be summarized by saying that 1) enterprises should embrace both, 2) if LSS is not in place, then EA should encourage the adoption, 3) they are separate initiatives, EA should not try to own LSS, and 4) EA should engage and partner with LSS for knowledge sharing and for, of course, keeping EA’s own processes “lean”.

References

Moresteam.com. (n.d.). Retrieved from https://www.moresteam.com/new-to-lean-six-sigma.cfm#lean

Daneman, Matthew. (2014). Xerox cutting back on Lean Six Sigma program, jobs.  Retrieved from http://safechild.org/categoryparents/preventing-bullying/

Measuring Complexity and Keeping It Simple

I’m about to undertake an initiative at my current place of work to measure complexity throughout the enterprise.  As an SMB, this is actually a realistic undertaking.  In my 18 months on the job, I have frequently lamented the enormous complexity-burden the business has built up over the years.  Every enterprise has more complexity than they would like, however, in over thirty years of experience, I can say that my current enterprise has built up a truly noteworthy and inglorious burden.  

In Chapter 1 of Enterprise Architecture As Strategy (Ross, Weill, & Robertson, 2006), we learned about the importance of building a foundation for execution. Some examples of an enterprise lacking such a foundation are:

1. Different parts of the company give different answers to the same questions.
2. The business lacks agility.
3. IT is consistently a bottleneck.

There were several other examples and all of them accurately describe the current state of my enterprise.  I would even add one more to the list, that being intractable quality issues.  The bottom line is, we need to build our foundation for execution by attacking our complexity.

As I mentioned, I repeatedly lament our complexity problems, however, talk is cheap and it is imperative that I do more to give meaning and substance to the issue, and to make it stick in the minds of the executives.  So, I decided to start by quantifying our complexity, which, admittedly, seems like a complex undertaking that should be doomed to fail due to its own complexity.

To drive home the complexity of assessing complexity, I offer the following text from the Harvard Business Review (Sargut, G., McGrath, Rita, 2011) describing complexity in the modern business and how to assess it.

Three properties determine the complexity of an environment. The first, multiplicity, refers to the number of potentially interacting elements. The second, interdependence, relates to how connected those elements are. The third, diversity, has to do with the degree of their heterogeneity. The greater the multiplicity, interdependence, and diversity, the greater the complexity.

I do not disagree with the theory whatsoever, but I also know that measuring the three properties of complexity are a non-starter - it truly is too complex, at least for me.  It seems then, the critical success factor in measuring complexity is to keep it simple - really simple.  

After a lot of thought and many spreadsheets, it hit me - just count things.  Nearly all problems that burden a workplace can be expressed in the form of a count.  For example, as a law firm, each of our clients (banks) have unique processing requirements that we have a difficult time keeping straight, which in turn leads to quality issues. So, let’s express this problem with a count and consider counting the number of clients with less than five cases per year (these clients add to our complexity without adding much to our revenue).  The bottom line is that a business or IT problem can almost always be expressed as a count.

Eventually, weighting factors will need to be added to show more importance to, say, the number of finance systems in use (a whopping five at my current SMB enterprise) versus something slightly more innocuous, like the number of different database versions we’re running.

A simple four column spreadsheet of 1) the name of the count, 2) the actual count, 3) the weighting factor, and 4) the product of 2 and 3 is what I’ll be using.  By summing up column 4, I’ll get my enterprise’s complexity factor, which, of course, over time we want to drive down.

Some guidelines I’m using for populating my list of counts are:

1. Structure or phrase the count so that simplification is measured by a reduction in the count.
2. Be sure to get the important counts (like the number of unique finance systems) without stressing over the less important counts.  However, when you trip across something, count it.  As an example, when an intranet website was down, I discovered that it was not running on our designated intranet web server.  This adds to our complexity, and even though it’s not a huge deal, it’s still a complexity I’d like to erase, as these small items do add up.
3. Don’t just count IT things, also count business things, such as the number of clients, the number of business units, the number of products, the number of states or countries operating in, the number of facilities, etc.  
4. Don’t avoid counting business things that would be considered negatives if the number went down, such as the number of clients or number of employees.  No matter what, the bigger the number, the greater the complexity, and the goal is to draw attention to the enterprise’s complexity.

This exercise/experiment is full of challenges, such as the subjectivity of the weighting factors, the difficulty of measuring progress if we keep tinkering with the weighting factors, or the difficulty of measure progress if we keep uncovering and adding pre-existing complexities.  

Nevertheless, counting things truly is simple.  It gives an EA Team a metric that can be measured and hopefully evolved into something meaningful and it will help permeate the thinking of the business, leading to decisions that simplify the enterprise, helping to create a foundation for execution.

References

Ross, Jeanne, Weill, Peter, Robertson, David. (2006). Enterprise Architecture As Strategy. Boston, MA: Harvard Business School Press

Sargut, G., McGrath, Rita. (2011, September). Learning to Live with Complexity. Retrieved from
 https://hbr.org/2011/09/learning-to-live-with-complexity

SLAs as an EA Tool

This week I want to write about service level agreements (SLAs) as a tool EA teams should use throughout the enterprise to drive improved performance and measurement.  In Chapter 2 of Enterprise Architecture As Strategy (Ross, Weill, & Robertson, 2006) the importance of defining a company’s operating model, and furthermore, on the integration between processes is stressed.  It is here, with the integration between processes, that SLAs should be applied.  

When operational problems arise at my current employer, it is fairly common for one department to lay blame on the preceding department (in the affected end-to-end business process).  The dispersions sound something like “If Team Xyz would only provide complete and accurate inputs to our team, then we’d be able to do our job properly.”  Ensuing discussions meander and usually devolve into a “venting” session rather than a constructive examination of the business process.

In a similar manner, there’s a catch-phrase we use of “clear to cheer” that is meant as a warning to teams that push for the rapid elimination of a backlog through overtime or incentives (hence the catchphrase, where clearing the backlog leads to cheers).  The reason for the warning is that the backlog problem simply gets passed on to the next department in the process.  We’re passing the problem on instead of solving the reason for the backlog.

The aforementioned are examples of what happens when the handoffs (the inputs and outputs) involved in a process are not formally defined and governed, and that’s where SLAs come in.  

SLAs are extremely common in IT and other service-oriented organizations, but not common at all among the operating departments within an enterprise or business unit.  Every inter-departmental handoff in an end-to-end process should be governed by an SLA, which will give us several benefits:

1. Clear departmental accountability.  Those meandering meetings with lots of “venting” will become more constructive.
2. Goal and objective setting for individuals and teams become easier and more quantitative.  
3. Strategic opportunities become clearer and the ability to analyze the impact of changes becomes easier when input and output requirements are defined.
4. SLAs will highlight the ideal granularity of business process documentation.  We learned about the “burden of knowledge” in “Enterprise Architecture Pitfalls - Current State First?” (Bittler, 2012), where EA teams are cautioned against documenting too much of the current state.  I would certainly characterize the documenting of processes within departments as a “burden of knowledge”, however, documenting processes at the level of each department-to-department hand-off (the SLA level) may be just the right level of process documentation.
5. SLAs give us a set of measurement requirements.  My blog posting from last week addressed designing for ease of measurement.  If our business processes have SLAs in place, then future technology projects can take these requirements and actually design for ease of measurement.

Last week I asserted that EA teams should take the lead in ensuring that enterprise’s design for ease of measurement.  This week, I will assert that EA teams should also take the lead in ensuring SLAs are a requirement for all inter-department processes. This strikes me as an opportunity for EA teams to show how they can positively impact the business and even transform it without always proposing new technology solutions.

References

Ross, Jeanne, Weill, Peter, Robertson, David. (2006). Enterprise Architecture As Strategy. Boston, MA: Harvard Business School Press

Bittler, Scott. (2012, January 31). Enterprise Architecture Pitfalls - Current State First?. Retrieved from Penn State EA-872 class material

Designing for Ease of Measurement

This past week I spent some time thinking about the importance of metrics in an EA program, and more specifically, the importance of metrics that have a strong connection to the business.  When it comes to a successful EA program, I’m more concerned about implementing business-oriented metrics as opposed to the metrics that are more internal to the EA Team, such as refresh cycles, the amount of staff trained, and the number of variances.  The business is going to care a lot more amount cost, quality, revenue, and productivity metrics than internal facing EA metrics.  It’s the business-oriented metrics that will drive engagement and a stronger partnership.

The problem with the business-oriented metrics is with the ability to follow through on them and to actually implement the measurements.  It seems wherever I go in my career, the list of desired business metrics is quite long while the list of business metrics that can easily be implemented and measured is extremely short.  

The reasons are typically the same - it’s the software systems and databases used for day-to-day operations.  They either don’t have the data needed, they have the data in a manner that makes the measurements complicated, difficult, and suspect, or there are multiple systems in use that makes data gathering extremely time-consuming and costly.  These are all problems that can be solved, but when time and cost are considered, the desired measurements get shelved for a more convenient time (which rarely arrives).

When contemplating this reality, I was struck by the notion that software and data structures usually are not designed with ease of measurement in mind (especially for business metrics).  We design for performance, we design for usability, we design for reusability, and we design for ease of maintenance, but I don’t think we design for ease of measurement.  We need to give ease of measurement serious forethought (rather than the typical afterthought) when designing systems and data structures.  

This is a natural area for EA to provide leadership and guidance throughout the neverending journey to the future state. If EA takes the lead on designing for ease of measurement, the business will become more engaged and the partnership between IT and the business will be strengthened.  One final thought from the world of Lean Six Sigma and the book “Making Quality Work: A Leadership Guide for the Results-Driven Manager” (Chang, Labovitz, Rosansky, 1994):

“The World-Class organization is continuously bathed in a stream of integrated data.”

References

Chang, Y.S., Labovitz, George, Rosansky, Victor. (1994). Making Quality Work: A Leadership Guide for the Results-Driven Manager, Oliver Wight Ltd Publishing

Enterprise Context - Anchor Models

In last week’s posting, I related the idea of an Enterprise Context as prescribed by Gartner (Gartner, 2011) to a software system’s Context Diagram, recasting it as an Enterprise Context Diagram (ECD). 

This week I want to show how the ECD fits into the process for launching EA, while adding some additional high-level models to the launch process.  Scott Bittler, a vice president at Gartner, gave a presentation at Penn State titled “Enterprise Architecture Pitfalls - Current State First?” (2012).  This presentation cautions EA teams against initially focusing on the current state of the enterprise, providing the following reasons:

• Working on the current state delays time-to-value
• It’s a never-ending exercise as the current state is always changing
• Focusing on the current state encourages incremental thinking
• Creates a “burden of knowledge” which hinders creative work on the future state.

The presentation makes a strong case for EA teams to avoid focusing on the current state when starting their EA programs.  Gartner’s recommendation for EA launch deliverables is referred to, collectively, as the Enterprise Context.  The Enterprise Context is comprised of:

• Trends
• Business Strategy
• Requirements
• Principles
• A single anchor model

It is the notion of a single anchor model that is my focus this week.  The presentation states that this bullet should be taken verbatim, recommending that during the EA launch process, there should be one current state model that captures the entire enterprise, all in a single picture.

While I agree with the idea that EA teams should avoid starting with the current state, I recommend SMBs take advantage of their smaller enterprise footprint and expand the anchor model concept from a single model to a small anchor model series.  Here are the current state models that I recommend for an anchor model series, as part of the overall Enterprise Context deliverables:

• Enterprise Context Diagram - The details of this model can be found in last week’s posting.  I recommend an ECD for the full enterprise and one for each separate business unit, as the unique environment of each business unit is important to see when planning for the future state.  Each ECD is only one page each, so the effort should be reasonably small.

• Organization Diagram - This is a slight decomposition of the ECDs, which takes the box representing the enterprise and expands it to add the organizations directly involved in the production process (the departments that add the value described in the value proposition) and the supporting departments such as HR, IT, and Finance (generic default management example).

• Enterprise Information Model (EIM) - The EIM resembles a data model, but without any data attributes and absolutely no representation of application-specific information.  It simply shows the major business entities that describe the enterprise and how they relate to each other, much like Gartner’s “Bank XYZ Deliverables Navigation Guide” shows how all the EA Deliverables relate to each other (generic default management example).

These three models will provide three important, yet simple, high-level views of the enterprise.

1. The ECD shows the external environment (for the full enterprise and business unit levels).

2. The Organization Diagram shows the high-level organization, distinguishing production departments from support departments while retaining the context of the external environment.

3. The EIM shows the important informational assets and how they related, without the enterprise’s environment or structural organization to complicate it.

The models recommended above will provide an SMB with exactly what models are supposed to provide, that being unique views or perspectives of the same enterprise.  This makes for a simple, yet powerful current state representation with minimal time invested.  This series of anchor models, when combined with the rest of the Enterprise Context deliverables, will give the SMB a solid launching point for EA while retaining Gartner’s recommendation for minimizing the current state efforts during launch.

References

Gartner. (March 2, 2011). EA Must Include Defining Your Enterprise Context

Bittler, S. (2012, January 31). Enterprise Architecture Pitfalls - Current State First?. Retrieved from Penn State EA-872 class material

Gartner. (n.d.). Bank XYZ Deliverables Navigation Guide.  Retrieved from Penn State EA-872 class material

Enterprise Context Diagrams

We learned in EA-871 that the most important deliverable from an EA initiative is “change” (Gartner Clarifies the Definition of the Term 'Enterprise Architecture, 2008).  I completely agree with that assertion, however, in the nascent phases, I believe the primary deliverable needs be a establishing a common language between the business and IT.   

At my current employer, the business has a difficult time expressing their needs and issues, while IT consistently has difficulty understanding the business and rarely knows when information is incomplete or inaccurate. This problem is severely exacerbated by the fact that the business is a high-volume law firm - a business domain notoriously known for confusing jargon (worse than IT in my humble opinion).  We need to improve our communication, we need a common language, and I believe that starts with establishing proper context for the enterprise and the business units within, which is the focus of Gartner’s paper “Q&A: Why EA Needs an Enterprise Context (2011).

Gartner mixes several elements into the Enterprise Context, such as strategies, trends, principles, and the development of core models.  It is the development of one specific core model that I want to focus on - the Context Diagram - the first and most important model in my opinion, whether there is a formal EA program in place or not.  

As a software developer at EDS, I learned about Context Diagrams as part of EDS’ Software Development Methodology (SDM), which borrowed from the structured analysis and design research by Ed Yourdon, et al. (1970s).  Context Diagrams were conceived as a software analysis and design tool with the purpose of conveying the simplest and highest level representation of a software system.  The entire system would be represented by a circle in the middle, with all the inputs and outputs notated around it (a simple hub and spoke diagram).  This establishes the system’s context, or in other words, its environment.  See the Context Diagram example below.

Basic Context Diagram

What struck me in changing my thinking from software development to enterprise architecture, is that an enterprise, like a software application, is a system with inputs and outputs, and the exact same Context Model can, and should, be used to describe an enterprise at the highest level and in its simplest form.  There does not need to be any changes to the theoretical approach whatsoever.  The middle circle is simply a system of any type (anything with inputs, some form of transformation, and outputs) and since all systems must have inputs and outputs, we notate the sources and targets around the middle circle and then notate what is exchanged.  We have now fully established the environment of the enterprise (on one page!), which, at my current SMB, not a single person from hourly staff to the top-level executives has full awareness of.  What a great foundation to build a common language from. I'm including (below) an example Enterprise Context Diagram for a generic default management law firm (my current business domain), to illustrate what a small leap it is from a software analysis and design tool to an EA tool.

Enterprise Context Diagram for a Generic Default Management Law Firm

There are three important points to make an Enterprise Context Diagram as effective as possible:

• First, remember that this is now a business model, not an IT-centric application model, so when notating the exchanges, do not limit your thinking to digital information.  You should be capturing all exchanges, be they digital, raw materials, or finished products.
    
• Second, do limit the input and output relationships to those involved in the enterprise’s value proposition.  In other words, don’t capture the relationship with the firm that restocks the vending machines in the lunchroom.  This is ancillary to the value proposition and does not need to be expressed.  
  
• Third, include the enterprise’s value proposition on the Context Diagram.  It should be short enough to include in the corner.  When a clear, short value proposition is combined with a graphical depiction, it makes for a powerful sheet of paper.

A final recommendation is to remember that an Enterprise Context Diagram is also a starting point for further decomposition down to the business units, lines of business, and departments.  They are all systems that can, and eventually, should be expressed with a simple one page Context Diagram.

References

Gartner. (2008). Gartner Clarifies the Definition of the Term 'Enterprise Architecture

Gartner. (2011). Q&A: Why EA Needs an Enterprise Context

Yourdon, et al. (1970s). Structured Analysis and Design Methods

EA for SMBs

The past eight years of my thirty-plus year career have been at two small-to-midsized businesses or SMBs, as I’ll refer to them hereupon.  The prior twenty-plus years were spent at public corporations with sales in the billions and employees in the thousands.  For context I’ll offer Gartner’s definition of an SMB from their IT Glossary:

A small and midsize business (SMB) is a business which, due to its size, has different IT requirements—and often faces different IT challenges—than do large enterprises, and whose IT resources (usually budget and staff) are often highly constrained. For the purposes of its research, Gartner defines SMBs by the number of employees and annual revenue they have. The attribute used most often is number of employees; small businesses are usually defined as organizations with fewer than 100 employees; midsize enterprises are those organizations with 100 to 999 employees. The second most popular attribute used to define the SMB market is annual revenue: small business is usually defined as organizations with less than $50 million in annual revenue; midsize enterprise is defined as organizations that make more than $50 million, but less than $1 billion in annual revenue.

Prior to enrolling in the EA program, I asked some program representatives from Penn State if EA was just a big company thing or if the importance extended to SMBs.  The answer was an emphatic “yes it’s just as important to SMBs”, as I knew it would be, and as I already believed.  However, real-world EA, both in practice and in theory, seems tilted toward the “bigs” (which will be my hereto reference for any organization bigger than an SMB) as it probably should be, but not to the exclusion of SMBs.  Some of my observations:

1. Out of four primary business experiences during my career, the two bigs had EA programs as far back as the 1990s, while the two SMBs, to this very day, have more of a shoot-from-the-hip approach to IT (and a lot of chaos to show for it).
2. Most of the books, articles, and research material, if not written specifically from the perspective of a big, seem to imply the context of a big.
3. Most of the students in the EA program are from bigs or the government sector.

 

My point being, the bigs seem well represented; the SMBs, maybe not so much.  With that said, my intention for this blog is to make EA theory, with its genesis in the bigs, more relatable and pertinent to SMBs.  

I knew I wanted to make SMBs the focus of this blog while going through this week’s EA872 readings, which address wise execution of EA, with the implication that EA has already been sold and introduced to the enterprise.  I think selling the concept of EA in large enterprises, while not trivial or easy, is still somewhat of a forgone conclusion.  The bigs seem to accept the need, they mostly trip on the execution.  The SMBs struggle with formality and will resist buy-in from the beginning if offered only promises.  

To offer a couple of examples of how EA theory for the bigs can be slightly morphed so it is a bit more pertinent to the SMBs, let’s consider two articles from Gartner: Enterprise Architecture: Just Enough, Just In Time (2006) and EA Must Include Defining Your Enterprise Context (2011). Both articles contain lessons and recommendations for managing scope while in execution mode.  As I put forth above, SMBs have buy-in challenges and one of the best ways to address this challenge, is to execute EA in a limited fashion without necessarily formalizing it - IT leadership at SMBs have this flexibility.  By following the recommendations from the articles for developing a small set of valuable models and for defining the enterprise context, both reasonable undertakings at an SMB without the need for investment, we can show real-world value to leadership and use that as the plan for selling a broader EA program.    

It’s kind of like the notion with job promotions, where people will do a job before they’re given the title, then when given the title, they continue to do the same job with maybe slightly expanded responsibilities.  At an SMB, it seems wise to do some EA before selling it as a formalized initiative, after which, we will continue to gradually expand EA’s reach and impact.