/Tag: Architecture

Enterprise Architects should consider IT value streams

By |2016-08-07T01:06:10+00:00August 7th, 2016|Newsletter|

Businesses are increasingly looking for IT to be more efficient and to add significant value. In order to achieve this outcome enterprise architects need to consider the value streams in the organizations that add up to business value, according to one expert.

Rick Solis, the IT business architect at ExxonMobil, voiced his opinions during an Open Group conference in Austin in July. Solis has a wealth of knowledge in the area having focused on applications and technology strategy for the ‘business of IT’. His speech at the event looked at how ExxonMobil is leveraging IT4IT to grow their integrated strategic planning process. (more…)

Sharing the Solution Domain Taxonomy

By |2015-04-23T10:17:18+00:00April 23rd, 2015|Enterprise Architecture|

Sometimes, Enterprise Architecture efforts fail.  This is no surprise to folks in the EA business.  This failure occurred slowly, back in 2007 and 2008.  But it did occur.  It took me a while to realize it. 

I had developed a method useful for Application Portfolio Management as well as for Service Oriented Architecture called “Solution Domains”.  The method is good.  It’s a framework and taxonomy for high level descriptions of software so that generalized services can be created AND so that the portfolio of applications can be rationalized.

The method is good.  But I failed to position it’s use in the appropriate enterprise program in the appropriate way.  I failed.  Not the method.  Where we used the method, it worked brilliantly. 

I’ve learned from my mistakes, but being unwilling to let a good thing go to waste, I’m sharing the Solution Domain taxonomy with the world.  It’s not patentable (I tried).  It is useful, however, because it is a part of a business method that supports Application Portfolio Management in a completely technology agnostic manner as well as Middle-Out SOA.

I’ve put the entire taxonomy on my Enterprise Business Motivation Model site at: http://motivationmodel.com/wp/application-portfolio-management-and-solution-domains/ 

I may return here, at some point, and provide further details on how it can be effectively used.  For now, back to work!

How brand-thinking can kill you, and capability thinking can save you

By |2015-01-29T19:12:50+00:00January 29th, 2015|Enterprise Architecture|

I guess it shouldn’t surprise me that business strategy work is often about constrained thinking.  Thinking “inside the box” is nearly always rewarded well.  After all, the person giving the rewards lives in the same box.  One of the most pernicious kinds of constrained thinking is “brand thinking.”  That is the notion that the value of your existing brand is the starting point for all your products.  Living within the box of the brand is definitely constrained thinking.

Brand thinking says “everyone knows us for doing this one thing well, so let’s invest in variations on that thing.”  That’s great.  And it often works.  For example, the Dell computer company has a great reputation for building good (but not wildly innovative) personal computers for individuals.  So naturally, when they decided to diversify, they decided that they should build on that brand.  They decided to build server computers for businesses.  It worked fairly well.  As they tried to become more innovative, they had problems with the brand.  In some areas, Dell simply bought other brands (Alienware for gaming computers, for example).

On the other hand, brand-thinking also leads to a kind of situational blindness.  Essentially, we choose not to see the things we think are outside the brand, or even the market, that we are used to.  And in doing so, we nearly always miss opportunities.  At least, until our competition points them out to us.  Dell was good at electronics manufacturing to the home.  Had they looked outside their brand, and focused on their abilities, perhaps in the 1990s, they would have been successful competing with Sony or Sharp for personal electronics.  Brand thinking says “no.” They stuck to computing, moving into printers, laptops, and tablets.  All have suffered from the “commoditization” of their market. 

A strategist is a unique role.  To be a successful strategist, you have to do everything you can to resist the boundaries of constrained thinking.  But then your ideas have to be judged by people who are PAID based on constrained thinking.  And that’s a tough sell.

Capability Modeling

When we do business capability modeling, we are looking not at the products of a company, or it’s brand, but at what that company can do.  We look at what a company has the people to do, the processes to do, the information to do, and the tools or technologies to do.  We bring together this knowledge into a complex model of elements, and summarize it as a capability map. 

The value of doing this is typically revealed when creating initiatives for the execution of strategy.  If a company is doing incremental strategy, there may be one or two areas that have slowed or prevented the company from achieving its goals with respect to its competition.  But when a company is following an innovative strategy, there may be a dozen different capabilities that need attention.  Some may have to be created from scratch.  Capability modeling is a clearly valuable tool in this arena.

However, there is another use for capability modeling that is not often discussed, and that is the need for unconstrained thinking on the part of the strategist. 

Could Capability Modeling have saved Kodak?

If you are over the age of 30, and live in a western country, you’ve probably heard of Eastman Kodak.  Known for their near monopoly on film and film processing, Kodak was the undisputed king of photography for decades.  In 1990, they held 90% market share.  They were unbeatable.  Remember this logo?  It was a very successful brand.

Let’s assume Kodak had done a capability model back in 1990 and had actually paid attention to it.  They would not look at their brand or their existing products, but at the things that they do very well.  What would be on that list of “things they do well?”

  • R&D in chemical-based manufacturing
  • Manufacturing of plastic and chemical based products
  • Manufacturing of specially treated paper
  • Manufacturing of chemical processing equipment
  • Consumer-focused marketing
  • Motion-picture-industry marketing

Let’s be clear here. These capabilities were not just solid.  They were the best in the world. 

What’s not on here?  Electronics.  Electronics manufacturing.  Electronics R&D. Electronics Marketing.  Not on the list.

So when Kodak started to see the need to expand, they used brand thinking.  People see the brand “Kodak” and think photography.  So why not go into the manufacturing of digital cameras?

Do you see anything on that list of capabilities that deals with innovation and manufacturing of digital cameras? Heck, they didn’t make that many analog cameras (Nikon, Olympus, and Canon made most of the analog cameras).  They had no distribution network, no reputation, no capabilities, no core skills to make cameras of any kind, and certainly not digital cameras. 

Even though they were able to leverage their brand for a while, eventually their ability to sell digital cameras fell away and they lost money.  Huge sums. At the same time that their analog film business was also losing money.

Now, look at that list again.  What do you see?  Ignore the fact that this is a film company.  Do you see other things there?

The simplest capability to build is the ability to market to a new segment.  The hardest is the ability to do R&D and manufacturing well, so let’s drop the marketing for a moment. Not completely, but let’s focus on the hard stuff.  Could they have built products based on treated plastics and treated paper?  Almost certainly.  There’s an entire industry that makes sheets of plastic film for a wide array of different purposes from glass protection to window tinting.  What about chemistry based R&D?  Could they have created innovative consumer products to compete with companies like Clorox or Proctor and Gamble? Could they have leveraged their chops in chemistry to compete with companies like 3M?  Maybe.  But only if they had looked first at their core capabilities.

The important thing to note about these industries is that they have not been disrupted by technology the same way that camera film was.  While these industries are not easy to compete in, the ability to leverage existing world-class capabilities is more critical to success than the ability to leverage the brand. 

Eastman Kodak thought of themselves in the film and photography business.  And it was their downfall.  Unfortunately, it still is.

And now a challenge…

What about this brand?  What are their core capabilities?  And what can they be doing with those capabilities? 

Are they on the precipice of disruption?  You bet.

American Express logo

Moving Towards a Theory of Enterprise Architecture

By |2015-01-16T13:28:41+00:00January 16th, 2015|Enterprise Architecture|

I’ve been asked a number of times over the years if I can explain the theory of Enterprise Architecture.  I decided recently to reopen that idea.  It’s not a new discussion.  I refer to Tom Graves post on the Theory of EA from 2012 where he posits that the theory of EA, if one were to be described, cannot be used to prove the value of an EA design.  The not-so-subtle hint is that there is, therefore, no value in creating a theory at all.  I disagree.  I believe that there is value in developing a theory of enterprise architecture. 

Let me first recap my gentle readers on what I mean by a “theory of EA.” 

Typically, in science, we start with observations.  Observations are objectively real.  They should be mathematical and measurable.  They exist within a natural setting and may vary from one setting to another.  We may observe a relationship between those observations.  The goal is to explain those observations in a manner that is good enough to predict outcomes.  To do this, we suggest a hypothesis, which is simply a guess.  We then see if we can prove or disprove the hypothesis using data.  If we cannot disprove the hypothesis, we have passed our first test.  We use the hypothesis to predict new observations.  We then check to see if the predictions are correct.  If so, we have a useful theory

Underlying Observations

Theories are created to explain observations and help predict new ones.  So what kinds of observations would I include in the Theory of Enterprise Architecture?

  1. The rate at which companies can adapt to change varies widely from company to company. Let’s call this the “rate of potential change” (RPC) because it refers not to the actual rate of change, but the potential rate of change which will never be less than the actual rate, but may in fact be more.
     
  2. This rate is important to the survival and health of a company.  Companies can die very quickly when their marketplace is “shocked” by a big change in customer expectations or competitive offerings.  If the Rate of Potential Change (RPC) is high enough, then any shock to the marketplace can be absorbed by an enterprise by responding competitively.  The cost of response appears to increase exponentially as time from the shock increases.  For example, from the date Amazon announced their cloud platform to the date that Microsoft produced a product that was as good as the Amazon initial offering, the time that elapsed created a steep obstacle for Microsoft to overcome.  The cost of overcoming that obstacle is much higher than if Microsoft had been able to respond sooner. The faster you can respond, the more chance you have of survival.  RPC measures how fast you can respond.
  3. The Rate of Potential Change (RPC) appears to be correlated with observable factors like the amount of alignment between strategy and execution, the quality and testability of company strategies, and the measurable maturity of key capabilities for absorbing and coping with change.

These observations need to be measured, collected, and validated.  And we need more observations to be researched, shared, and enumerated.  We don’t know quite what EA explains just yet, and building out the list of observations gives us a place to start.

The EA Hypothesis

At the highest level, the basic premise of Enterprise Architecture is simple:

The EA Hypothesis: The structure of and both intentional and unintentional relationships among enterprise systems has a direct and measurable influence on the rate of potential change and organizational cost of operating and maintaining those systems.

That simple statement is quite powerful. 

The EA hypothesis demands that we create a definition for “enterprise system” and a method for describing the “structure” of an enterprise with respect to those systems and to describe the “relationships” between them.  Clearly an enterprise system has to include socio cultural systems, information technology systems, workflow systems, and governance systems.    

The EA hypothesis suggests that the relationships between these systems are important.  That the relationships themselves influence the rate of potential change. as well as the cost to own a system.

The EA hypothesis demands that we measure the rate of potential change, and that we describe “organizational cost.” To do the latter, we must develop a clear idea of what is involved in operating and maintaining each of the included systems. 

The hypothesis is also fairly unbounded.  It leaves us with important questions to answer.

  • Can we cleanly and concisely define what we mean by “system” so that two architects independently examining the same enterprise would develop the same list of systems?
  • What are the types of relationships among systems and how do we differentiate relationship?  What attributes do these relationships have?  What attributes make sense?
  • Does it apply to one system?  A subset of systems? or can it only be truly understood to apply to the complete system-of-systems that is, in effect, a complete description of the enterprise?
  • What standard methods can we develop for identifying ALL of the relevant systems of an enterprise quickly and effectively for the sake of understanding the architecture of the enterprise?

I’m intentionally not answering these questions here because it is rational to leave all of these questions open for scientific research.  It is entirely possible that the answers may help us separate useful EA models from useless ones.  It is simply too soon to tell.

Why the EA Hypothesis matters

The rationale for creating an EA hypothesis is the requirement, often expressed through strategy, placed on an enterprise by its senior leaders, to do one of two things:

  1. improve the quality and reduce the organizational cost* of performing existing enterprise capabilities, or
  2. creating or expanding capabilities in an enterprise through targeted, specific and managed changes to the network of systems

This matters because nearly all strategy hits one of these two buckets.  This goes from corporate strategy all the way down to personal improvement: either you are improving your production, or your production capacity.  Either you doing what you know how to do, or you are learning new things.  Either you are getting better at the normal stuff, or innovating to add new stuff. 

Enterprise architects are called upon to help in both ways.  We have to answer questions like: “what does “innovation X” do for us, and what does it do to us?” We also have to contribute to ongoing concerns like “how do I grow my business in “Market Segment Y” in an innovative and compelling way?” and “How do I cut the cost of our IT expenditures?” and “How do I improve the quality of my customer data?”  These questions fall under the category of “organizational cost”.

* Cost and quality come together to include a balance of monetary cost, effectiveness, customer satisfaction, efficiency, speed, security, reliability, and many other system quality attributes.

We need a clear theory of Enterprise Architecture because answering these questions is difficult to do well. We have operated without a theory because we were able to “guess and check.”  We would guess an the scope and value
of an initiative, undertake it, and check on its value later.  But we are not able to say, in advance, that “proposed initiative A” is foolish compared to “proposed initiative B” because we have no science here.  It’s all just “guess and check.”

The term “guess and check” is not new.  My kids learned to use the “guess and check” method in elementary school math class as a way of exploring a problem.  But that’s where the “guess and check” method belongs.  Elementary school.  Grown ups use proven science.

All except EA.  We still use “guess and check.”  It’s time to grow up.

Next steps

  • First off, we need a long list of valid observations that we are trying to explain and understand.  The naturalists of a hundred years ago started with detailed drawings and descriptions of plants and animals and the habitats that they inhabit.  Perhaps we should start with detailed drawings and descriptions of the structure of different enterprises and the niches that they operate in.  We also need a valid way to measure and observe the “Rate of Potential Change” in an organization.
  • Secondly, we need simple reusable methods for conducting research in the area.  A consistent way to count and categorize systems, for example, and an accepted methodology for measuring their cost and quality that can be applied across different types of systems and companies.
  • Lastly, we need evidence of the cause and effect of making changes.  We need a solidly understood and measured system to be captured in a snapshot, and then a series of changes results in another solidly understood and measured system.  That gives us evidence of the value of the changes. 

 

Moving forward from here requires research. More on that connection in another blog entry.

Do you perform Information Architecture or a Data Architecture?

By |2016-07-10T00:41:37+00:00November 21st, 2014|Enterprise Architecture|

So, full disclosure, I care about Wikipedia.  Call me dumb, I know.  Wikipedia has been described, alternatively, as the best platform ever invented for fostering useless arguments among ignorant people /and/ the most successful encyclopedia effort of all time.  The truth, as always, lies between these extremes.

Well, I’m part of a small team that is working to clean up the Wikipedia pages dealing with Enterprise Architecture.  One thing that we noted recently is the fact that there are two pages, similar, both rather poor, that cover essentially the same topic.

One page is called “Information Architecture” and the other is called “Data Architecture.”

(more…)

The Architecture Manager – the Forgotten Enterprise Architecture Role

By |2014-11-11T16:46:03+00:00November 11th, 2014|Enterprise Architecture|

I’ve met many Architecture Managers over the years.  Sometimes they go by the title of “Chief Enterprise Architect” or “Chief IT Architect” and other times, the title is “Vice President of Architecture and Strategy” or some variant.  The men and women called to serve in this unique role have a distinct, and uniquely important role to play in the success of the Enterprise Architecture function in their enterprise.  Yet precious little is said about them.

In this article, I’ll touch one some of the key qualities I would expect to find in a successful Architecture Manager.

What value does an Architecture Manager provide

As the role of Enterprise Architect matures in organizations around the world, we’ve begun to see the tremendous impact that an effective architecture manager provides.  In many ways, the Architecture Manager is the single most important role in the department, but also the most difficult role to fill.  That is because, typically, the role is filled by a person who “moves up” from being an Enterprise Architect.  Unfortunately, being an excellent EA is poor preparation for this particular role.

An Architecture manager is:

  • An expert at “selling upwards” – Convincing management of the need, role, measures, and successes of the EA function as a whole.
     
  • An expert as “peer selling” – Convincing enterprise peers of the value of requiring their staff to collaborate with an architect, especially when doing so forces a change on the processes they would otherwise use.   (this is one of the most difficult and valuable activities an Architecture Manager can do).
     
  • A visionary for the development of the function – Convincing the team, the management, and internal partners of the vision and desired impact of Enterprise Architecture in the organization, keeping in mind both short term and long term goals.   Without vision, the function cannot grow. 
     
  • A good people and resource manager – Capable of aligning people to roles that can be successfully performed, helping his or her staff to grow to meet their potential, and finding new resources from within and without the enterprise capable of performing an architecture function.   It’s amazing how many architects move up to a manager role and have no idea how to do this well.  This blind spot can kill a team within a year.

 

In my travels, I’ve met both good Architecture Managers and not-so-good Architecture Managers.  The ones in need of improvement nearly always struggled at one of the above.

What are the responsibilities of an Architecture Manager

Enterprise Architects are rare birds… especially good ones.  There are many folks who have worked to become Enterprise Architects, and a few who succeeded in recognizing the uniquely holistic role of an EA.  Typically an EA has to manage through influence alone, because it’s rare that an EA has a team of resources assigned to him or her.  But an Architecture Manager is in a different position.  They do have a team, and unlike other efforts where they could be objective about a business leader’s business processes and functional alignment, they now have to perform architecture on themselves.  Sometimes, they succeed.

If you find you need to hire an architecture manager, you’ll need a list of responsibilities for your hiring team.  Just copy the following list.

The responsibilities of an Architecture Manager include:

  • To set the vision, goals, and measures of success for the Enterprise Architecture function within an enterprise, recognizing the current team maturity, skills of the team members, and readiness of the enterprise to accept the role as desired.
  • To measure the value of the efforts of the Enterprise Architecture function in a neutral manner and present those measures at appropriate times to stakeholders within the enterprise to earn buy in for the function and the funding it requires.
  • To create, refine, and oversee execution of the internal processes of the Enterprise Architecture function, including documenting processes, building support for points of interaction, and ensuring the deliverables match the expectations and timing needed by internal partners and stakeholders.
  • To manage the team members of the Enterprise Architecture function effectively and within the required parameters set by Human Resources.  This includes hiring staff, setting team goals, and conducting performance reviews.
  • To manage the assignment of resources to necessary priorities within the enterprise to meet conflicting strategic needs, and shielding the team members from being pulled out of role.
  • To act as an evangelist for the role of Enterprise Architect within the enterprise, working to build support for the function and its staff members among internal partners.

 

What should an Architecture Manager know

Some of this is pretty obvious, but it’s worth stating anyway.  The architecture manager has to be familiar with enterprise architecture.  But they also have to be familiar with how things can work in an organization, especially if the focus of the EA program is related to IT (as it nearly always is).

  • Experience with and understanding of the deliverables and value proposition of Enterprise Architecture.
  • Deep understanding of the methods and processes an appropriate EA framework. 
    • For telecom, this would be Frameworx (formerly NGOSS and eTOM).
    • For US federal government, that would be the FEA or DODAF.  (in different countries, there are different governmental frameworks). 
    • For private business, the leading frameworks would be TOGAF in first, with a tiny number of organizations still using Zachman. 
    • A small but growing number of companies use the Pragmatic EA Framework (PEAF). 
    • Most organizations roll their own, often from TOGAF, so starting there is the safest.  Note that a certification in TOGAF or the Zachman Framework is a great start.
  • Strong written and oral communication skills
  • Strong and demonstrable systems thinking and strategic thinking skills.  The ability to capture the key elements of a system into a simple abstraction that empowers good decisions.
  • Solid business financial skills.  Demonstrable ability to perform cost benefit analysis and manage the budget of a team.
  • Strong business negotiation skills, influence, conflict resolution, and political savvy
  • Demonstrable leadership in Portfolio Management, Project Management and Enterprise Change Management
  • Multiple years of Strategic Planning experience, preferably in a governance role

 

What should an Architecture Manager NOT do

In many cases, people who move into the role of Architecture Manager worked their way to that role as an architect.  They may have been a technical architect, solution architect, business architect, or enterprise architect.  In many organizations, these roles are deeply technical.  Of all the architecture managers I’ve met, the overwhelming majority are technologists.

Unfortunately, most technologists don’t have the skills to focus on the responsibilities listed above.  It is tempting to continue to be a technologist once moving to this role.  It is also suicide.  Your term as the “Vice President of Strategy and Architecture” will be short if you cannot step back and let your team perform the technologies or modeling activities typical of an architect.  This means, for the architecture manager himself or
herself: No modeling,  No coding,  No time spent geeking out.  (Ok, exception, fiddling on the side is fine, especially if you want to “stay warm” with your technical skills… but nothing deliverable.)

Where should I look to find a good Architecture Manager

First place is the same as you’d expect for any role: find a person who was successful as an Architecture Manager in another enterprise.  Be careful of people who performed  but did not succeed as an Architecture Manager.  Most folks fail.  Find out if the function continued after they left, and if their team enjoyed working for them, and if their stakeholders saw fit to provide an increased level of interaction with their staff members.  Look at examples of their teams’ deliverables and ask about their ability to build and maintain new business processes.

Second option is to bring in an experienced architect and let them take on the role.  Assuming the team already exists and is well accepted within the organization, this is a reasonable approach.  Finding a seasoned architecture manager is extraordinarily difficult, so this may be the only rational option.  The person you select should have worked for at least six years as an Enterprise level architect, with increasing levels of responsibility, and should preferably have been a resource manager at some other point in their career.  If the program does not already exist, see the next section.

Third option is a seasoned manager who has no experience as an Enterprise Architect.  This may be a distinguished technical architect, or the leader of a highly visible program in the past.  These folks are expected to bring expert team leadership skills and deep technical skills.  The biggest challenge that they will face is being able to adequately learn the role.  Unlike most other management roles, the Architecture Manager must be able to SELL the value of the role of Enterprise Architect, and that is extraordinarily difficult to do if the manager wasn’t an architect first.  The learning curve is very steep.  To pull this off, the Architecture Manager will need a good mentor or an experienced consultant to help guide them through the first year in role. 

Building a program around an Architecture Manager

If you don’t already have a functioning Enterprise Architecture program, your very first hire will be the Architecture manager.  This role will be doing a great deal of heavy lifting in that first year.  Setting up processes and deliverables.  Making sure that the stakeholders buy in to collaborating with those processes.  Hiring and situating staff.  Creating priorities and managing resources.  Setting up measurement and demonstrating value.  It’s a tough road to build from scratch while providing value.

The only advice I can give: do NOT build a new EA program around an Enterprise Architect who has never been an Architecture Manager before.  That is simply too much for a single person to handle.  Going from EA to Architecture Manager of a new program is a huge leap, and I have never seen it be a successful approach in the long term.  The person you hire may be a “survivor” who knows how to avoid being fired, but that won’t make them effective.  Once they move to another role in the enterprise, the function will likely vanish.

You need the Architecture Manager to be effective.  To build a program with lasting value.  To build a program that matures over time. 

So if you are building a new EA program, build it around an experienced Architecture Manager.  Then support them with resources that they did not ask for: (a) an outside expert who can provide a neutral point of view and sounding board as they build and struggle that first year, and (b) Serious “air cover” so that they have the time needed to build the team, create the processes, build support, and demonstrate early value.

Conclusion

The single most important person in the Enterprise Architecture function is the Architecture Manager.  This critical role is part visionary, part marketer, part people manager, and part evangelist.  They have to change the organization and keep the change from undoing itself.  The role of Enterprise Architecture is highly dependent upon the skills and the focus of this key role.  Choose wisely.

When does EA start to care about sociocultural influences?

By |2014-08-13T11:24:38+00:00August 13th, 2014|Enterprise Architecture|

Organizations do not work, in real life, like they work on paper.  On paper, there are departments (all shaped like a neat rectangle) and business processes with neat inflows and outflows of responsibility and information.  On paper, you improve things by modeling things on paper, and then moving things around, on paper, then teaching people to follow the process that your neat paper diagrams represent.

In real life, there are human beings and the tools that they use.  Sometimes the tools move information from one person to another.  Sometimes, they just aid in communication.  People meet and get to know other people, and they learn to trust some, and distrust others.  Some folks have different measures and motivations and just “pass by” one another.  Some subset of these people will have shared cultural values and expectations.  There may be many cultures in an organization: both because the organization is in multiple places, and because people from multiple places join an organization.  Also, “business culture” arises as leaders achieve successes and people learn to use certain “cultural expectations” to get things done efficiently. 

Reality is a lot messier than pretty rectangles. 

Enterprise Architects apply science and engineering and aesthetics to the challenge of organizational change.  We are unique in that most other “change artists” are not focused on engineering and some even ignore science.  (see Daniel Pink’s TED Talk on the Surprising Science of Motivation).  Few even know how to spell aesthetics.  Yet, when you are dealing with systems that contain and include people, you have to use aesthetics, and you are ill prepared for success if you ignore science.  Engineering is a mindset as much as a class of methods.  It involves applying the things that science has discovered and using that understanding to build great (and sometimes terrible) things.  Engineers build on ideas and use them, often experimenting on systems that are too complex and intertwined for “pure science” to get arms around.

As Enterprise Architecture is such a young science, we have relied to heavily on the “boxes and lines” model of enterprises, and not enough on the messy but important sociocultural view of an enterprise.  We find it easier to document, and model, and even simulate, processes as though people were interchangeable and their relationships didn’t matter. 

That is just lazy.

It is time to get up off our collective butts and start working out ways to understand sociocultural influences, relationships, and architectures.  We have to build ways to detect, measure, and consider these structures when we measure capabilities, or improve processes, or suggest automations, or evaluate business models, or any of the two dozen things that EA’s do. 

The value of EA often comes to an executive in the form of a reasoned opinion that is based on data that no one else is looking at.  Let’s consider the possibility that examining sociocultural influences can provide interesting opinions that an executive will find valuable.

We should consider sociocultural information if:

  1. Sociocultural influencers can impact the speed of change in an organization.
  2. Sociocultural connections can impact the decision making and governance processes
  3. Sociocultural strengths would allow rapid improvement in business capabilities needed for a shift in strategy
  4. Sociocultural blind spots would prevent an organization from recognizing an existential threat

 

Think about it.  Do you believe that any of those statements are false?  I can find ample examples for each one.  So if sociocultural interactions matter, why are we not tracking them, learning from them, using them to make decisions?

It’s only hard because we haven’t tried.

(This post inspired by the many similar pleas shared by J.D. Beckingham in social media).

Being Forgotten in the Internet of Things

By |2014-06-30T11:04:28+00:00June 30th, 2014|Enterprise Architecture|

We all know that Google lost a landmark legal case recently.  As of now, a citizen of Europe has the “right to be forgotten” on the Internet.  As of now, a citizen of Europe can ask Google to “forget” them, so that a search of their identity will not return embarrassing information from the past.  This allows a person to live past a mistake.  Your college indiscretion, and that time you were fired for photocopying your butt, or the time you got drunk and drove your car into a swamp and had to be rescued… all of that can “go away.”

However, this becomes much more difficult when we consider the emerging Internet of Things (IoT).  In the Internet of Things, the “stuff” that you own can generate streams of data that do not remain within your control.  That data is called “Information Property.”  It is the information that YOU generate, in the things that you do.  I believe that if YOU create a bit of information property, you should own it.

That information property, thousands of tiny bits of data about you or your activities, will wander out of your house, or your car, or your phone, to companies and governments running cloud-based data centers.  That swarm of data surrounds you, and be used to profile you, track you, predict your actions, influence your choices, and limit your abilities to get “outside” the system.  Most folks will not have any problem with this cloud of data.  At least not at first. 

Where we will first feel the pain of this cloud of data: when you want to be forgotten.

A parallel that does work

We have been dealing with “data about you” for a while.  When you apply for a loan or a credit card, the information you submit becomes the property of your creditor, and they share that data with credit reporting agencies, along with your payment history, employment history, residential history, status of property ownership, and basically any other factor that finance companies feel would influence your likelihood to pay your debts.  The US Federal Government has placed some controls on this data, but not many.  Europe has placed entirely different controls.  You have no right to be forgotten, but you do have the right to limit their memory to a decade.  That allows you to “get past” a mistake or series of mistakes.  But you are always “known.”  However, a mistake can be forgotten. 

This is a model we can use.  Here is data, about you, outside your control, that get’s “forgotten” on a regular basis as it gets old.  There is a possibility in the credit reporting world for being “forgotten” because the data is tied to you, personally.  It is ALL personal data. 

This is not (yet) true in the Internet of Things.  If your car sends data to a smart roadway system, there is a great deal of information about where you go, and when, but under most circumstances, your identity is not tied to that data.  It’s the identity of the CAR that is sent, but not the identity of the driver or passenger.  That can be seen as an advantage, because it is tough to link that data to you, but it is possible, and therefore it will occur.  You will be found.  And when it does occur, you no longer have any easy mechanism to PROVE that the data from your car relates to you. This means that if any government creates a policy to allow you to be forgotten, the car data will not go away.  You can’t CLAIM that data because it is not directly linked to you.  You don’t own it.

Think this is a minor problem?  After all, your city doesn’t have a smart roadway yet, and your car doesn’t send data, so this problem is a long way off, right?  Wrong.  If we don’t think of this now, privacy will be sacrificed, possibly for decades. 

The environment of regulations sets the platform by which companies create their business models.  If we create a world where you cannot claim your data, and you cannot manage your data, other people will start claiming your data, and making money.  Once that happens, new regulations amount to government “taking money” from a company.  The typical government response is to “grandfather” existing practices (or to protect them outright).  No chance to change beyond a snail’s pace at that time.

A proposal

I propose a simple mechanism.  Every time you purchase a device on the IoT, you insert an ID into the device.  This ID is a globally unique ID (my tech friends call this a GUID) which is essentially a very large random number.  You can pick up as many as you want over your lifetime, but I’d suggest getting a new one every month.  A simple app can create the GUID and manage them.  Every item you purchase during that month gets the ID for that month.

Every bit of data (or Information property) sent by the device to the swarm of companies that will collect and work with this data will get your GUID.

Note that your GUID allows those companies to link your data across devices (your phone, your car, your refrigerator, your ATM card, your medical record, etc).  Is this allowed?  Perhaps one government or another will say “no” but that control will be easily worked around, so let’s assume that you cannot control this.  The thing I want to point out is that this kind of linkage is POSSIBLE now, it’s just more difficult.  But difficulty is being overcome at a huge rate with the number of computing devices growing geometrically.  Let’s assume that folks can do this NOW and that you will NEVER be able to control it.

Therefore inserting an ID is not giving up control.  You don’t have it now.

But it is possible, with the ID, to TAKE control.  You will be able to submit a request to a regulated data management company (a category that doesn’t yet exist, but it is possible), then those systems can identify all the data records with your ID, and delete them.  Only if you can claim your data can you delete it.  By inserting a GUID into your Internet-of-things, you have gained a right… the right to claim your data, and therefore delete it.

It will no longer be a choice of sending a single message to a single search firm like Google.  The request to delete will have to go to a broker that will distribute the request, over time, to a swarm of data management companies, to remove data tagged with these IDs. 

Some implications

Now, before anyone complains that a company, once they have data, will never let it go, I would submit that is nonsense.  90% of the value of information comes from samples of that data of less than 2% of the population.  In fact, the vast majority of data will be useless, and plenty of companies will be looking for excuses to toss data into the virtual trash bin.  If a customer asks to delete data, it costs a micro-cent to do it, but that data is probably clogging things up anyway. 

Getting a company to spend the money will probably require regulations from large players like the EU, the USA, China, Japan, Brazil, and India. 

The time to act is now

Now is the time to ask for these regulations, as the Internet of Things is just getting started.  Companies that understand the ability to create and manage these IDs, and respond to the request to delete information, will have a leg up on their competition.  Customers will trust these companies more, and the data will be more accurate for consumers of these data services. 

You cannot delete “information property” until you can claim it.  The ID is the claim. 

EA Debt

By |2014-06-24T23:41:00+00:00June 24th, 2014|Enterprise Architecture|

(Note: I’ve added an addendum to this post)

It has been many years that we have lived with the concept of technical debt.  Martin Fowler did a good job of describing the concept in a 2003 article on his wiki.  Basically, the idea is that you can make a quick-and-dirty change to software.  You will have to spend time to fix that software later.  That additional time is like an interest payment on debt that you incur when you made the change.  Fixing the code to make it more elegant and clean “pays down the debt” so that future changes cost less to make.

I’d like my fellow practitioners to consider joining me in extending this idea to the enterprise.

Organizations change, and sometimes the changes have to be made quickly.  Processes that are implemented “quick and dirty” may have poorly defined roles, overlapping responsibilities, and duplicate accountabilities.  It may work, and it may be necessary to hit a deadline.  However, these “dirty” processes have the same problem that dirty code does – it costs more later to fix them. 

In a sense, partial process or accountability “fixes” in an organization create “enterprise architecture debt” or “EA debt.”  We run into it all the time in organizations.  Here are some examples that I’ve personally seen:

  • One team is responsible for checking the quality of all manufactured products and making sure that they get to distributors.  However, products that are custom developed have their own quality check and distribution function.  Effectively, two different teams duplicate a couple of functions.  This could be simplified, and doing so would likely reduce costs and improve consistency in quality checks. 
     
  • The marketing team uses data mining techniques to identify potential customers (prospects) and enters them into a system along with attributes like segment, predicted value, and targeting within specific marketing programs.  When a new customer reaches out to actually purchase a product, however, the customer record is created in a CRM system that is not linked to the marketing record.  Consistently linked customer information could provide valuable information about the effectiveness of marketing programs as well as enriching customer information for the sale of service and ongoing sales.
      
  • An outpatient specialty radiology department in a Hospital requires patients to be registered separately from other hospital services in order for patients to be handled.  For most patients, this is not a problem.  However, for patients within the hospital, the separate registration requirement creates opportunities for errors as information is hand-transcribed from one system to another.
     
  • A retailer sets up an e-commerce division to sell their wares online.  However, inventory and warehousing the new e-commerce site is not integrated into existing store systems.  The ecommerce “store” is treated as another physical store.  This works, but any attempt to allow customers to purchase online and pick up at a store become problematic because the retailer has no way to handle purchases made in one store to be fulfilled by another.
     

These, and a thousand more situations, are the result of “partial” or “messy” implementation of organizational changes.  They are a form of “EA debt” because any change to the organization that hits these capabilities will be more expensive to change in the future as complexity slows down the organization.  In effect, EA debt is like taking a Lego set and gluing the pieces together.  The parts will remain just as they are, but the will be very difficult to change in the future if something needs to change.  (Apologies to “The Lego Movie” for the metaphor).

Why call this “EA debt?”  Because it is not a financial term.  It is nearly impossible to accurately measure all of the EA debt in an organization.  It is, however, fairly straight forward to measure monetary debt.  So we have to be careful not to use terms like “enterprise debt” or “organizational debt” as these may be confused with general accounting concepts.  Just as technology teams sometimes twist the concept of an “asset” to apply to an information system, Enterprise architects are using the metaphor of debt to refer to one of the root causes of difficulty in making organizational change.

Addendum: I guess I shouldn’t be surprised that this idea is not novel.  It’s fairly self-evident.  It was my mistake that I didn’t go looking for other references to the idea before writing the above post.  Laziness.  No excuse.  While the concept of technical debt does in fact trace back to Ward Cunningham (inventor of the Wiki), as discussed by Martin Fowler in the referenced blog post, the application of that concept was first applied to EA in 2008 in the Pragmatic EA Framework, and is part of the current version as well.  I’d give a link to that presentation if I could but the best I’m able to do at this time is a general link to PEAF at http://www.pragmaticea.com.  Kevin directly responded below with links into his material .  It is no disgrace to be in the shadow of Kevin Smith (author of PEAF).  It is an error, however, to appear to originate the idea.  For that, my apologies.

Climbing the ladder from EITA to EA

By |2014-03-10T13:50:59+00:00March 10th, 2014|Enterprise Architecture|

One of the most common problems in Enterprise Architecture, and one I get asked about routinely, is the “ladder” problem.  Many Enterprise Architecture teams are formed by assembling a group of talented technologists into a team and giving them a charter to “go do EA.”  The problem is that most of these teams have no credibility outside the technology group, and cannot really operate as a “bridge between business and IT” if they don’t have the relationships and knowledge that they need to be an Enterprise Architect.  Building those relationships and that credibility takes time… sometimes many years.  Until they make that transition, the team is an Enterprise IT Architecture team (EITA) and while that is useful, the value proposition of EA remains unfulfilled.

I call this “climbing the ladder” from EITA to EA. 

While the entire team should work on this, only a few will succeed.  Good news: That’s all you need.  However, it’s important that everyone makes the attempt to climb the ladder.  As a manager, I have no magic “test” to determine, for certain, which member of the team will make the transition and which won’t.  I once thought I did, but reality proved me wrong.  So everyone makes the attempt.  Those who remain EITA’s can continue in that role for the EA team, or they can transfer to a different group where their technical skills are valuable and needed.

So, how is this done?  How does an individual EITA climb the ladder?

You need four things:

  1. business knowledge
  2. empathy (and good reflective communication skills)
  3. courage
  4. air cover

Business Knowledge

Business knowledge is the one that should, on the surface, be the easiest of the three to acquire.  Unfortunately, it seems to be one that is sorely lacking among EITA’s who are attempting to make this transition.  What do I mean by business knowledge?  I mean the ability to understand the basic concepts of business at a working level.  In other words, can you answer these questions coherently:

  1. Explain the difference between value and cost from the perspective of the provider of a product or service
  2. For Contoso in Q4 CY2013, they saw sales to new customers increase while market share decreased.  Explain.
  3. Give an example of a disruption in bricks-and-mortar business triggered by mobile computing
  4. When your company acquires another company for cash, explain how the balance sheet is impacted
  5. Explain how opening a new channel for your customers can result in a decrease in sales
  6. Give an example of a good strategy that failed in your industry or market.  Why did it happen?

Where do you get business knowledge?  There are a gazillion books that will give you the basics.  Universities are helpful as well.  With the wide array of support, Enterprise IT Architects should have no difficulty learning these things… yet it’s startling how many don’t.  I have some friends who insist that an MBA is needed.  I disagree with that, but college courses do help.  I hold out the most hope for success with a blended program like that offered by the Enterprise Architecture degree at Pennsylvania State University. 

Empathy and Communication Skills

There has been a good bit of ink spilled about technical topics: mobile platforms, SOA, security, etc.  These help with the EITA side of the job.  But they don’t do much for the architect who needs to climb the ladder.  To successfully make that move, most architects need to invest in training on their soft skills.  This means building up the following:

  • Listening – Can you elicit the emotional context behind your stakeholders strategies and goals?  Can you truly “hear” them?  There are courses, and books, and online videos, that can help you to become a more conscious listener.  Not only will this help you climb the ladder, it will also help you in your relationships with family and friends. 
     
  • Empathy – The art of empathy in business is one where you feel as your stakeholder feels.  Don’t confuse with sympathy.  Big difference.  Empathy is a selfless act, and your ego has to be put into check if you are going to learn empathy.  There are many folks in architecture who struggle with ego, ambition, and condescension.  I struggle as well.  But if you don’t tame this beast, and build your capacity for empathy, your stakeholders will have a difficult time connecting with you.  As the old saying goes: They won’t care what you know, unless they know that you care. 
     
  • Negotiation – You will be frequently called upon to find a way for two people, with different perspectives, to come to a solution where both people “win”.  These “win-win” solutions form the basis for successful endeavors of many kinds, not just in business.  But if you don’t know how to negotiate, your usefulness as a bridge-builder is seriously limited. 
     
  • Positional Awareness – this means the ability to “see” how the organization works from various perspectives, and to position yourself, and your value proposition as to provide you the ability to influence that system.  It also means being aware when other folks are doing the same thing, which has the effect of changing your landscape out from under you.  Some folks call this “politics.”  I call it necessary.
     
  • Selling – Yep, I said the dreaded “s” word.  Many architects view “sales” as a dirty word.  After all, Sales people use emotions, leverage relationships, and often don’t even understand the details of what they are selling.  The sale is more important than the actual people!  Ouch.  It’s true.  Sales professionals are often competitive individuals who have been known to compromise their integrity for the sake of the transaction.  But that doesn’t mean that the tools and techniques of sales aren’t useful, or effective, or critical to success.  These techniques are mission critical.  So take professional training in sales.  How to hook a lead.  How to build excitement.  How to connect to your stakeholders’ underlying motivations.  How to use emotion to communicate.  How to ask for the sale.  How to follow up.   The use of color, design, and simplicity to convey a message.  All of that. 

Courage

Did you know that courage can be learned?  I guess I always knew it was possible, but I never really considered it until I found myself with a situation where I needed to use courage, and needed others to do the same.  I was playing the role of a SOA architect, and I needed to convince development teams and technical architects to adopt a set of patterns that would help the enterprise, but may actually add complexity to their own project.  I needed to walk into rooms and see if I could demonstrate, convince, cajole, argue, and/or negotiate my way to changes that were not in the obvious best interests of the team itself. 

I taught myself courage.  I taught others courage as well.  Part of teaching, and learning to be courageous, is to put your efforts into perspective.  See your work as necessary to a “bigger picture” and be very aware of how much you can get away with before others decide that they cannot actually follow your lead or support your efforts.

Courage is not the lack of fear or operating outside of dangerous situations.  It is the conscious choice to move ahead despite danger.  As the Will Smith character in “After Earth” tries to teach his son, “D
anger is real.  Fear is a choice.”  Sometimes, as an Enterprise Architect, you will have to tell someone powerful something that they don’t want to hear.  The situation can end badly, impacting your ability to continue working as an Enterprise Architect, or worse, resulting in you losing your job.  These dangers are very real to many EAs. 

Courage means that you will need to move ahead anyway.  It does not mean you should be reckless in the face of danger.  It is OK to be cautious at times.  But real success often requires boldness, and your bold actions cannot be made without the courage of your convictions.      

Air cover

There is a difference between “being courageous” and “being stupid.”  The difference is support: do you have the support you need, by someone higher up the food chain, to take on the challenge of climbing the ladder in most organizations.  This support from above is critical to your success.  I call it “air cover” (a reference to a military situation where ground troops can request a deadly strike on an enemy to be dropped from planes, missiles, or artillery). 

In a business setting, air cover means that you have successfully convinced leaders in various places around the company that you can be trusted.  They believe that you are valuable and that your motivations are in the right place.  So when a problem occurs, or one of your standards is challenged, or your roadmap makes a stakeholder angry, that leader can step in and sooth sore egos. 

I cannot indicate the importance of air cover.  For architecture managers, if you don’t provide air cover for your team, you are worse than an ineffective leader… you are a disgrace.  And for architecture practitioners, if you don’t build the relationships you need to build so that you will have the air cover when you need it, you are not being courageous.  You’re being stupid, reckless, or chaotic (take your pick).  To climb the ladder, someone has to be holding the ladder.  That’s your air cover. 

Conclusion

Climbing the ladder is a difficult challenge for any Enterprise IT Architect (EITA).  It takes dedication, support, and some significant innate abilities.  However, for many who take on this challenge, the rewards are excellent.  I truly love Enterprise Strategy Architecture.  I hope to see many of you “in the trenches” with me, fighting to make our ecosystems healthier, stronger, and more agile every day. 

Caveat: certification and frameworks

You’ll notice that I never mentioned Certifications or Frameworks in the discussion above.  That’s because I’ve met and known hundreds of Enterprise Architects.  Certification was only useful to make them more effective as an EITA.  It made no difference for climbing the ladder.  Certification will help with some skills and a great deal of knowledge.   A certification may build confidence, reduce churn in your team, and make your results easier for others to read and follow.  I’m not putting down certifications.  I’m just pointing out that this step comes with experience, not certification.  At least, not yet.

Technorati Tags: