We do what you say we will do – Integrity By Architecture

by

One of the chief complaints of senior executives in midsize and large companies is that their organizations don’t “execute” on the goals that they set.  This concern is so common, it’s the butt of jokes.  Entire systems of governance and measurement are created specifically to provide assurance to senior execs so that they can maintain some level of public integrity.  Yet, when Enterprise Architects describe their roles to their peers, it is surprisingly rare to hear them talk about this issue.  That is a mistake.  Let’s talk about how to tell the story of Enterprise Architecture as the maintainer of executive integrity.

In 2003, when Motorola sent their CEO Chris Galvin packing, USA Today wrote about what a “good guy” he was:

He turned out to be a lackluster CEO, which, sadly, often seems to be the case when good guys land in the corner office. Friday, Motorola said Galvin would resign. Motorola under Galvin had suffered through six years of disappointing results, laid off one-third of its workforce, failed hugely on new ventures like Iridium, and waited for turnarounds that never happened. The board apparently had had enough; Galvin thought he’d better leave.

I have to say I feel bad for Galvin. Of course, I wasn’t a Motorola shareholder who watched the stock go from $60 (split-adjusted) in 2000 to about $11 last week. Nor am I a laid-off Motorola employee. And yes, Galvin was paid handsomely: $2.8 million in salary and bonus last year.

Did Galvin fail, or did Motorola fail to execute on Galvin’s strategy?  The board of Motorola, and the board of any company, won’t see a difference.  Note that this story has happened over and over in high-tech, from Steve Ballmer to Michael Dell, usually without the board firing their CEO.  Far from being limited to high-tech, stories abound of retailers (Best Buy), manufacturers (General Motors), and financial services companies (too many to name) that have suffered through strategies that failed to pay off.

Here’s what stockholders see: you said “X” would happen and it didn’t.  You lied. 

From their perspective, the CEO loses credibility for lack of integrity.

Integrity is a personality trait and a virtue.  A person has integrity when they can be trusted to perform exactly as they said that they would perform.  In other words, they “do what they said they would do.”  This person makes a commitment and keeps it.  This means that they make commitments that they are fairly sure that they CAN keep, and they don’t forget the commitments that they made.  In every high-performing team that I’ve been a part of, each member had a high level of integrity.  Integrity is key to developing trust.  If you do what you say you will do, people will trust you.

Executives need to develop trust just as much as individual contributors do.   For private for-profit organizations, those stakeholders own stock, and purchase the goods and services of the company.  For public organizations, those stakeholders are voters and legislators.  Where an individual contributor must earn the trust of his manager and his or her peers, an executive is in a very visible position.  They have to build trust daily. 

Building that trust requires that they make bold pronouncements about the things that the organization will do under their leadership… and then their organization has to perform those activities.  And that’s a key difference.  When an individual contributor says “I will do this,” they are talking about their own performance.  Rarely are individual contributors held accountable for failures of the people that they cannot control.  Executives, on the other hand, are not talking about their personal performance.  They are talking about the performance of the many (often hundreds, sometimes thousands) of people under them. 

An executive doesn’t actually “control” the people under him.  He or she must lead them.  Sure, there can be an occasional “public hanging” (as Jack Welsh used to encourage), but, for the most part, the executive’s ability to speak with integrity comes from the trust he has in his organization to perform.  In other words, how will with “they” correctly do what “I” said they would do?

Enterprise Architecture is a keeper of executive integrity

Enterprise Architecture is the only profession (that I know of) that is focused on making sure that the strategy announced by an executive actually comes to pass.  Enterprise Architects exist to make sure that the needed programs are created, and executed well, keeping in mind the end goals all along the way.  EA’s go where angels fear to tread: to execute strategies and produce the desired results if they can be produced. 

If you value executive integrity, EA is an investment worth making.

What Has Governance Ever Done for Me?

by

This is basically the question that many project managers ask me when we have a discussion about adhering to governance. They want to know what value their project gets from adhering to governance processes, from generating artefacts for governance gates. The short answer is “none – governance is not something we do for you!” If […]

Three laws of the next Internet of Things – the new platforming evolution in computing

by

By Mark Skilton, Global Director at Capgemini There is a wave of new devices and services that are growing in strength extending the boundary of what is possible in today’s internet driven economy and lifestyle.   A striking feature is the … Continue reading →

Your Company Doesn’t WANT a Business Architecture

by

I am a business architect. I believe in its value and see it producing unimaginable results on a regular basis. However, I am also realistic about the challenges of starting a business architecture practice. Too many potential business architects are squandering their opportunities by not recognizing and accepting the challenges to selling the idea. They […]

Enterprise Architecture: Balancing simplicity with complexity

by

Albert Einstein is sometimes attributed to having said that “Everything should be made as simple as possible, but no simpler.”  As a counterpoint and with some deference to Occam’s razor ‘Nothing should more complex than is necessary.’ Enterprise Architecture is … Continue reading →

Agile Business Modeling – The Core Heuristic?

by

How many times have I heard that the real problem with Agile is getting to the start line? There has to be some definition up front, but Agile methods don’t really help. Perhaps it’s a little secret for many organizations that they feel they must do more specification work up front because it makes it easier to control the Sprints. Oh dear!

To get to this starting gate we need to model the agile business in an Agile manner (YES!). Further we do not want to undertake complete or detailed business architecture (NO!!). We don’t have time, and anyway the core of the innovation and architecture should be done in the Agile Delivery project. But before we can fire up Agile projects we need to determine the scope and charter. If we use conventional scoping methods we may well deliver great functionality very quickly, but we probably won’t, unless we are very lucky, have delivered agile business capabilities that map to the business dynamics and can evolve along with the business.

Here’s a technique that may help.

In the first image below I show a functional decomposition for complaints management which I have clustered into “candidate capabilities” labelled 1, 2 and 3, process management, customer relationships and analysis respectively. This usefully shows that capabilities can be varying levels of abstraction; there’s absolutely no necessity to have elegant models!  The table below the decomposition shows various criteria I used to help me decide on the possible clusters. As you will see there’s variation in strategic classification; the partitioning – which may be key for deployment, some could be centralized others local; and the need for implementation independence and so on.

This analysis certainly helps me present some choices. But aside from the independence and scalability criteria and possibly standardization criteria, I feel I have not fully exhausted the analysis of the need for business agility. In the table below I develop this a little further. First I make an assessment of the potential requirement for future change in each function. I call this Agility Potential (AP) on a 1=Low and 5=High scale [1]. Not surprisingly Analysis and Skills are the capabilities that will probably be subject to considerable volatility. Second I look at the dependencies between the functions; note you have to read this as each row dependency upon a column. And low and behold, Skills and Analysis, and Analysis and Follow-up have high dependencies. This causes me to reconsider my initial cut of capability boundaries. I feel that Skills needs to be very close to Analysis as the investigatory function. And Follow-up should be similarly very close to Analysis. And what’s more these three functions score most highly on the AP scale. I feel Follow-up could easily be collapsed into Analysis, and a name change to Investigation would be perfect. I think a little more deeply about Skills. The degree to which the outcomes of Investigation need to be fed into Skills on a dynamic basis will vary depending on the type of business. If this was a safety critical business, I might recommend consolidating Skills and Investigation and renaming it Knowledge Management. But this really would depend on the business sector specific needs. 
To recap, what I have done here is developed a sharper understanding of the capabilities, and I have attributed them with governance criteria (in the first table) – I know what I must have delivered, and I am communicating some really important information to the delivery team, without constraining them at all on the implementation and delivery method. Also I now know the dependencies between the capabilities, and we can very quickly resolve the services that will be required and the inter project dependencies. And it didn’t take me very long at all.

More on Agile Business Modeling 

[1] I first outlined the idea of Agility Potential in the CBDI Journal April, 2010. Let me know if you would like a copy.

Agile Business Modeling – The Core Heuristic?

by

How many times have I heard that the real problem with Agile is getting to the start line? There has to be some definition up front, but Agile methods don’t really help. Perhaps it’s a little secret for many organizations that they feel they must do more specification work up front because it makes it easier to control the Sprints. Oh dear!

To get to this starting gate we need to model the agile business in an Agile manner (YES!). Further we do not want to undertake complete or detailed business architecture (NO!!). We don’t have time, and anyway the core of the innovation and architecture should be done in the Agile Delivery project. But before we can fire up Agile projects we need to determine the scope and charter. If we use conventional scoping methods we may well deliver great functionality very quickly, but we probably won’t, unless we are very lucky, have delivered agile business capabilities that map to the business dynamics and can evolve along with the business.

Here’s a technique that may help.

In the first image below I show a functional decomposition for complaints management which I have clustered into “candidate capabilities” labelled 1, 2 and 3, process management, customer relationships and analysis respectively. This usefully shows that capabilities can be varying levels of abstraction; there’s absolutely no necessity to have elegant models!  The table below the decomposition shows various criteria I used to help me decide on the possible clusters. As you will see there’s variation in strategic classification; the partitioning – which may be key for deployment, some could be centralized others local; and the need for implementation independence and so on.

This analysis certainly helps me present some choices. But aside from the independence and scalability criteria and possibly standardization criteria, I feel I have not fully exhausted the analysis of the need for business agility. In the table below I develop this a little further. First I make an assessment of the potential requirement for future change in each function. I call this Agility Potential (AP) on a 1=Low and 5=High scale [1]. Not surprisingly Analysis and Skills are the capabilities that will probably be subject to considerable volatility. Second I look at the dependencies between the functions; note you have to read this as each row dependency upon a column. And low and behold, Skills and Analysis, and Analysis and Follow-up have high dependencies. This causes me to reconsider my initial cut of capability boundaries. I feel that Skills needs to be very close to Analysis as the investigatory function. And Follow-up should be similarly very close to Analysis. And what’s more these three functions score most highly on the AP scale. I feel Follow-up could easily be collapsed into Analysis, and a name change to Investigation would be perfect. I think a little more deeply about Skills. The degree to which the outcomes of Investigation need to be fed into Skills on a dynamic basis will vary depending on the type of business. If this was a safety critical business, I might recommend consolidating Skills and Investigation and renaming it Knowledge Management. But this really would depend on the business sector specific needs. 
To recap, what I have done here is developed a sharper understanding of the capabilities, and I have attributed them with governance criteria (in the first table) – I know what I must have delivered, and I am communicating some really important information to the delivery team, without constraining them at all on the implementation and delivery method. Also I now know the dependencies between the capabilities, and we can very quickly resolve the services that will be required and the inter project dependencies. And it didn’t take me very long at all.

More on Agile Business Modeling 

[1] I first outlined the idea of Agility Potential in the CBDI Journal April, 2010. Let me know if you would like a copy.

Mom says Save Up; I say do it with Application Rationalization

by

In part 7 of “Memoirs of an Enterprise Architect” I tested your knowledge on data classification and compliance.  Well, I have good news for this week.  There will not be another quiz so you can just sit back, relax and maybe learn a thing or two…

Categories Uncategorized

EA Myths

by

A recurring theme in enterprise architecture forums and debates is: “How do we demonstrate the value of EA or justify architectural overhead?” Some may view these discussions as academic, which compounds the problem, because it supports the idea that enterprise architects don’t really understand their role, that they don’t have a common definition of enterprise Read more

EA Myths

by

A recurring theme in enterprise architecture forums and debates is: “How do we demonstrate the value of EA or justify architectural overhead?” Some may view these discussions as academic, which compounds the problem, because it supports the idea that enterprise architects don’t really understand their role, that they don’t have a common definition of enterprise …

Read more