Nick Malik – Page 4

A practical set of EA deliverables

May 31, 2013 by Nick Malik

A question on LinkedIn recently reminded me that, as the team leader for Segment Architecture in my former EA team, I was accountable for identifying a core set of deliverables for the team. The idea was that we could focus on defining standard formats and contents for these deliverables and, in doing so, we could start to measure both our output and our quality.

We only created pre-canned templates for a few of them. This is partly because the team was not mature enough in its practices to get consistency, and partly because Enterprise Architecture itself is not mature, or accepted, enough to have stakeholders that would notice if our deliverables meet an objective standard. Also this list is not intended to be comprehensive. The goal was to describe deliverables where it may possibly make sense to go for some level of consistency. Any EA could (and often did) create deliverables that were not on the list.

Perhaps it is time to share what we came up with.

Note that this list is the result of a single team doing its work, and is not representative of any “standards” effort across other EA groups. That said, I stand beside this list. I think it is a useful start. Note that many are technical in nature. I did not, in making this list, differentiate between BA and EITA deliverables. So if you are someone who believes that EA = BA + EITA, then you will see both sets of deliverables, intermixed, in the list below. If you are someone offended by the inclusion of technical architecture deliverables in an EA list… tough. I was working with reality.

Deliverable name	Why create it	Description
Architectural Point of View (or Technical Policy)	Provide clear input to Business or IT leadership on issues relevant to Enterprise Architecture	Short document describing a problem that requires attention and the opinion of EA for solving it.
Architectural Reference Model (or Architectural Pattern)	Provide clear input to IT project SMEs on optimal or preferable design options	Short document describing a set of concerns and a proven approach for addressing them
<Segment> Current State Model and Analysis	To demonstrate and communicate challenges inherent in current processes / systems / information	A collection of architectural models, including a context model, process models, and information models, as understood to currently exist , plus an analysis of issues and risks
<segment> Future State Vision and Model	To demonstrate the design of the future processes / systems / information needed by strategic intent.	A collection of architectural models that reflect a specific set of engineered changes
Governance Model and Analysis	Clarify roles and responsibilities and decision making processes for planning and oversight of initiatives	Process model, description of roles and responsibilities, and description of deliverables needed for planning, oversight and governance, along with implementation ROI and plans
M&A Business Case & Analysis	To provide a rationale for the acquisition of a company for the purpose of improving operational effectiveness. (M&A)	The document contains rationale including Competitive Analysis, SWOT / Twos analysis, and Strategic Alternatives Analysis
System Integration Recommendations Document	To set a vision for how key processes and systems shall be integrated into enterprise infrastructure (primarily M&A)	End to End business scenarios, Process and System Integration points, Risks and Issues for each integration concern, and an analysis of alternatives and recommendations
Value chain and operating model analysis	To clearly address gaps and strategic requirements for integrating or divesting a set of processes and/or systems (primarily M&A)	Target value chain and operating model for post-M&A future state. Mappings of key processes to or from the enterprise core diagram, and analysis of changes with the intent of composing key initiatives.
Enterprise Core Diagram	To clearly declare the processes and systems that are NOT core to the operations of the enterprise	A list of systems and processes mapped grouped into “ecosystems” that are clearly indicated as “core” and “edge” with analysis of governance
EARB Engagement Package	To demonstrate project level architectural quality to the EA Review Board	A pre-defined collection of project architectural models and artifacts.
Capability Model and Assessment	Provide clear basis for data collection for a segment	List of capabilities for a segment with assessment of capability maturity, etc.
Capability Gap Analysis	Highlight underperforming capabilities to focus investment	Map of capabilities needed by strategies, highlighting those needed investment, and listing relative and absolute program spend against each
<segment> Roadmap (a.k.a. Transition Plan)	To clarify the scope, timing, and dependencies between initiatives needed to deliver on a strategy	List of proposed initiatives and dependencies between them to deliver on strategic intent
Strategy Map and/or Balanced Scorecard	To clarify the strategies, goals, and objectives of a segment and allow for measurement and alignment	Categorized strategies, measures, and metrics for a specific timeframe and business scope
<segment> Process Model and Analysis	To clarify and build consensus on the business processes (as-is or to-be), and as input to process improvement / measurement	Models of processes, activities, information assets and system interaction points , and an analysis of opportunities to improve.
Enterprise Scenario and Analysis	To get clarity on the experience of a key stakeholder (often a customer or partner)	Textual and diagrammatic description of an experience, often with analysis to indicate opportunities
<segment> Information Model and Analysis	To improve understanding of requirements and the rationalization of design	Well-constructed information model, at one or more well-defined levels of abstraction, covering all aspects of a segment, aligned with EDM, along with an analysis of risks and issues
Platform Assessment	Capture ability of an app or platform to meet strategic needs	Collection of measurements, attributes, and mappings to an app or platform
Proof of Concept (POC) delivery	To create a design that demonstrates, and proves, an approach for solving difficult issues	A software deliverable and an architectural reference model (see above)
Record of Architectural Tradeoffs	To clearly communicate the tradeoffs made by architects on the customer’s behalf	Textual description of architectural decisions and the implications for the owner of the process / tool

The “Right” Representation of the EA Value Cycle

April 30, 2013 by Nick Malik

In the world of Enterprise Architecture, we are still creating “shared” understanding of how to tell our stakeholders what we do. There is no consistency in our diagrams or our descriptions just yet. This post will discuss the different ways we present the value stream of Enterprise Architecture and will attempt to select a particular viewpoint that can be useful for the majority of situations.

First, let’s address the most commonly shared representation: TOGAF. The TOGAF ADM model illustrates a sequence of activities that starts with a preliminary phase and works its way through each of the levels of architecture. Basically, TOGAF illustrates a straight-through process from phase A through phase H to develop and use architecture.

First off, I’m no huge fan of this illustration. I always wondered how you get to an architectural vision prior to considering the architecture of the business. Also, the notion of a center point focused around requirements management feels weirdly tactical. At the level of an Enterprise Architect, I’m dealing with strategies and measures of success. At the level of a technical architecture, the word “requirements” has an altogether different meaning. Grouping together the notion of “strategic needs” with “technical requirements” may make sense to a technologist, but I don’t know a single business stakeholder of EA that would agree with grouping those two rather distinct things.

Who is our audience?

These observations bring me to my first key consideration: If we want to communicate the value stream of Enterprise Architecture, we first should consider the audience, “who are we communicating to?” If we are communicating to a stakeholder of EA, we should show them the bits of EA that are relevant to them, and we should not show them the bits that are not.

It is not cynical to gloss over the complex bits of EA when talking to a business stakeholder… it is practical. In fact, we do it all the time. If you buy cable TV services, a person from the cable company may come to your house and install a coax cable to your home. He will mess around with a cable box for a few minutes, and then, if you are lucky, he will show you how to do simple things like changing channels and recording your favorite shows. Then, he’s off. He does NOT spend an hour describing the various technical aspects of signal transmission and digital carrier signals. Why should he? You don’t care. You want to watch TV, not get a degree in electrical engineering. And the same applies to EA.

Secondly, if we want to communicate EA, let’s recognize that different people interact with Enterprise Architecture in different ways. Business stakeholders will interact with Enterprise Architecture to ensure that their strategies are being executed effectively, with minimal interference, and producing a result that considers things like security, cost of ownership, and the ability to cope with rapid changes in the marketplace.

Recap:

We have to care who we are speaking to, and we have to reflect the things that they care about.
We have to show them the details that matter to them and obscure the details that don’t.
We should illustrate the activities in the context of the processes that they understand, and not at a conceptual level that may be difficult to relate to their daily experience.

The ADM from TOGAF is an odd bird, because it attempts to be all things to all people. It represents EA in a way that every stakeholder can use, but honestly, no stakeholder can use it. It is not wrong. Far from it. But it is not useful because it violates every single one of the rules above. The ADM reflects the EA viewpoint, but not the viewpoint of the customers of EA at a level that they can grasp, understand, and most importantly, use. So let’s keep the ADM in our court, and create a view of the EA process that is relevant to our stakeholders.

So who are our stakeholders? For the sake of this post, I’m going to select one set of stakeholders and ignore the rest. Is that correct? Nope, but it is practical for a blog post. What this means is that the rest of this post produces an answer of the “right” representation only for one class of stakeholders… another representation would likely be needed for different people. That is the nature of EA. Let’s not fret it.

Stakeholders: Non-technologists

There is a widely held view in Enterprise Architecture that an EA must be technically savvy in order to be effective. There are certainly business architects who are quite effective who are not technologists, but in order to move UP to the notion of an EA (which includes business architecture, information architecture, solution or application architecture, AND technology architecture), you would need to be technically capable.

I won’t belabor the point about whether it is correct to view Business Architecture as a subset of Enterprise Architecture. It is the wildly predominant view. (A poll that I put on LinkedIn that asked this question found that well over 80% of EA respondents agree that EA generally includes every aspect of business architecture. That’s pretty overwhelming.)

That said, our biggest struggles in EA rarely involve conversations with other architects. While there may be a great deal of confusion, there is rarely a lack of buy-in for architecture among architects, or even technologists. Our key challenge, when it comes to communication, comes when we are talking to non-technologists. In other words, the proverbial “business” stakeholders of EA. (Please don’t flame me about whether IT is part of the business or not. That is a useful conversation, but it is outside the scope of this post).

Therefore, for the rest of this post, I will focus on the non-technology stakeholders of Enterprise Architecture. These are people whose chief concerns are not technical concerns. We could say that they care about financial performance, role clarity, cycle time, cost effectiveness, market position, revenue growth, opportunity costs, business drivers, and many other factors outside the realm of technology concerns. People in this category include senior business leaders (CEO, COO, CFO, CIO, CMO, etc), as well as business unit leaders (General Managers, Sales Division Leaders, Product Development and Marketing, Customer Service, Online Services, etc).

In order to communicate directly and well to these folks, lets recognize that they don’t care about the aspects of architecture that are technology focused. While the WANT good technology, and will BENEFIT from good technology, they will assume that the technology issues can be handled effectively without bothering them with details. To refer to our previous metaphor, they want the cable company to handle the technology, so that they can deal with changing channels.

So, let’s take the ADM, and trim out the stuff that non technologists rely on, but don’t need to have a conversation about. They assume it is there. That includes the preliminary stage, as well as architectural vision, requirements management, information systems architecture, technology architecture, and architecture change management.

The ADM now looks a bit different. In fact, we can put it in a single row with a looping arrow. Note that, in TOGAF, the Business architecture phase includes both current state assessment and future state modeling.

Representing the processes of the non-technical stakeholder

We have removed the confusing bits from the view of the non-technical stakeholder, but it is tough to say that we are at the point where we are relevant. After all, the non technical stakeholder has a business process that he uses when working with changes to his or her business. We are not representing that process.

The process, frequently described in dozens of bits of EA literature, starts with an understanding of the current situation within the business. Then, when the business creates a strategy, we bring these two bits of information together (current state and strategy) to create a vision for the future. This is the order that the non technical stakeholder may recognize… not the generalized view of the ADM. So it is time to break apart and rearrange the bits a little bit. I will now step away from the “crop circles” representation since it is so far out of the experience of people who describe business processes.

In this view, we can begin to see the steps that an Enterprise Architect would perform that are visible to a non-technical stakeholder. Just for the sake of clarity, this doesn’t mean that the technical steps are absent… it just means that our technical efforts don’t have to be paraded around in front of our non-technical stakeholders.

Note that I relabeled the ADM steps.

Business Architecture becomes Current State Evaluation, and Strategy Development
Opportunities and Solutions becomes Future State Modeling
Migration Planning becomes Roadmap Development
Implementation Governance becomes two things: Funding and Initiation (the Project Portfolio Management aspects) and Oversight and Governance (the governance of ongoing activities).
Architecture Vision is cut down to only the elements relevant to the non-technical stakeholders: the evaluation of the current state of the enterprise.

Let me point out that the TOGAF process assumes a different order of activities than the diagram above. From the standpoint of the stakeholder, this is what makes sense, regardless of how TOGAF describes the stages. This is why I’m no big fan of TOGAF as a methodology. It doesn’t reflect reality. On the other hand, the elements above are fairly well understood.

Also note that I’m not saying that the substitutions listed above are equivalent. In fact, I’d argue violently that Business Architecture is far more than Current state evaluation and Strategy Development. However, from the viewpoint of the non-architect, business architecture is a process that is involved with the development of business models (current and future), and that’s about it. There is a great deal of effort that is not seen by the stakeholders.

In other words, the blue model above is only showing the tip of the iceberg, and relabeling the phases according to what is (approximately) visible, not what is actually there.

This is an important part of explaining an activity to a stakeholder, and it is a skill that every Enterprise Architect must get good at. You have to explain your activities in the context of what a stakeholder understand and recognizes… not in the context of all your work. It’s not about you. It’s about the stakeholder.

The Rules of Value Streams

There are a few problems with the view above. In order to understand the problems with that view, let’s mention a couple of rules for representing a value stream. We will use these concepts because the ability to describe EA in terms of a value stream is important. Value streams are sticky… they are easy to remember and easy to relate to. If we want to remove the barriers to adoption of EA, we could do far worse than using this technique. That said, there are some rules that we have to keep in mind:

A value stream does not illustrate dependencies that are not really there. Parallel efforts should be represented as parallel if that would improve understanding of how value is created.
The value stream is illustrated as a sequence of high level processes in a straight line from left to right. That said, a value stream must start with an event that is relevant to the customer who gets value. It must end with the deliver of that value. Any activity that is not part of that flow (from relevant starting point to value) should be represented “above” or “below” the value stream.
A value stream should be illustrated in its fully operational state. In other words, it should describe a process that is running, not one that hasn’t been created yet. Events that are relevant only for “start-up” activities can be included, but should not be the primary focus of a value stream.

So let’s apply rule #1. Is it true that the current state of the organization actually feeds the development of strategy? No. In fact, the evaluation of the current state can happen completely in parallel to the development of business strategy.

So the diagram could look like this one.

Here, we can see that there are, in fact, parallel activities for the understanding of the current state of the enterprise, and for the development of business strategy. Where they first intersect is in the development of the future state (the opportunities and solutions phase from the ADM model). You need both an understanding of the current situation and the needs of the future in order to describe where the organization should move towards.

Now, let’s apply rule #2. What is the event that the business considers to be relevant to start the value stream of Enterprise Architecture? The Development of Business Strategy, of course. So the flow should perhaps look more like the diagram below… (note, the arrows and activities are identical to the one above… the only thing different is the order on the page).

Now, let’s apply rule #3… that one is easy. The arrow at the bottom that says “First TIme EA” can simply be dropped. After all, the first time a process is run, it starts from somewhere. It is simply irrelevant to the non-technical stakeholder to point out where that starting position is.

Exception: if you run Enterprise Architecture as a consulting arrangement, you may want to leave that arrow in there. After all, you will need to illustrate where the consulting arrangement will start. That said, I have found that fewer and fewer EA initiatives begin with the hiring of a consulting firm.

Providing context

When we started with the ADM, we assumed that there was a 700+ page methodology and framework behind the image, describing each step and what is included. However, your stakeholder will not read the TOGAF or any other 700+ page body of information. That would be absurd. You need to add a little detail to the image to describe what is in each of these stages.

It’s also a good idea to “clean up” the diagram a little so that we use less space on the “arrows and boxes” and more engagement on the ideas of what is going on. So the next modification of the process looks like this:

This diagram is a better one for informing the non-technical stakeholders of your Enterprise Architecture program about what it is that you do. We remove a little of the “accuracy” about where an arrow starts and ends, but we add a great deal of context about what is happening along the way.

The “backward” arrow along the bottom clearly indicates that there are activities that flow outside the value stream but which are needed for each repeat of the cycle.

Final words

Is this a perfect representation of the EA process? I don’t believe in perfect things… just useful things. But it is better, in my opinion, than showing a non-technical stakeholder the ADM or one of the “box and arrow” models above. It uses the visual language of value streams and business process models, both widely recognized and used in business interactions. It explains itself without going into a lot of detail. And it clearly describes the end to end flow without restricting or dictating where Enterprise Architects start and stop (an important requirement, since maturing EA programs will change their scope as they mature).

I have shown this view to others, and some have wondered about the “backward flowing” process along the bottom. The alternative to showing something as “backward flowing” would be to illustrate it as a cycle (with arrows feeding “in” from the right and “out” from the left). If it is a challenge for you to view the diagram without those arrows, I apologize. I’d love to see other view of this model that illustrate the “cycle” in a way that still meets the “rules of the value stream” as discussed above.

I’d love to get feedback and insight from the community. What do you think? Does the last image above resonate? What would you do differently?

Accelerating Business Architecture

April 26, 2013 by Nick Malik

I have, on occasion, been asked to spend time with an Enterprise Architecture team to help that team improve their maturity. It’s a great opportunity for me to learn, and share, and work with some of the smartest people on earth: Enterprise Architects. Coming off of an excellent experience in Europe, I’d like to share some reflections. I won’t name my client company to save them from any possible embarrassment.

This was a rather unusual case for me. Typically, I’d do fairly simple things. I may review and evaluate some activities, train folks for a day on methods, or perform a maturity analysis and provide a report out. While each of these require expertise, none are particularly dynamic. Nothing that would really push me to learn and adapt. Not so this time.

In this case, an EA team, made up of mature, experienced architects, was being challenged by an hard-driving CIO to “climb the ladder” into a strategic role, and do it quickly. Since the team was distributed around the world, climbing that ladder (which is already difficult to do) was made all the more challenging by the limitations of communication at a distance. Each of the architects were peers, which meant consensus and a shared vision were critical. They needed to accelerate their progress.

First, to be blunt, I’m not new at this. I’ve conducted trainings and workshops in a wide array of places to a wide array of teams. I’ve attended dozens of EA trainings and workshops. I hold two EA certifications (and will soon have a third). But this particular engagement was challenging. It was challenging because the objectives were clear, ambitious, and very specific. Due to the singular vision of one particular architect (who reads this blog… yes, I mean you, PH), I had a very clear set of marching orders: accelerate the team towards impactful and relevant business architecture.

We held a series of exercises over two very full days in a beautiful country inn in Germany. In each session, I provided some concepts and some practical tips from my own experience, followed by an exercise that got the group out of their chairs and collaborating in teams. Over the course of those two days, the team decided, for itself,

what kind of Enterprise Architecture team they wanted to be,
what their vision and goals were,
what their specific enablers needed to be,
and developed four alternative candidate roadmaps to deliver on their goals.

Along the way, we discussed and practiced skills in business architecture, stakeholder relevance, alignment, and roadmap creation. In the follow-up day, we worked to create visual stories that can be used to “tell the story” of their transformation to their many stakeholders.

Honestly, that’s a hard road. In a typical EA team, that amount of work takes weeks on a fast track. I didn’t have weeks. I had two days. So I had to dig deep. Working from every one of the experiences I’ve had in Enterprise Architecture, and thining back on every workshop or seminars I’ve ever conducted or attended, I pulled together an approach that left very little room for deviation from those goals. We worked HARD, and I can honestly say that I learned as much from this team as they learned from me. I am so honored to have had the opportunity to work with them, and I honestly hope to have another opportunity someday.

What, you might ask, would the trainer learn from a training session? Not much, if I were a trainer and if this were a training session. But I’m not and this wasn’t. I’m an architect and architecture manager. I’m an execution and alignment expert. This was a team of mature, thoughtful, and expert architects, each with over two decades of architecture experience. No, this was no training. This was guided empowerment.

When you work with people who are, in all rights, your peers, and you work to create something that you know is magnificently difficult to do, and you succeed, you learn. I certainly did. I deepened my respect for the talent and experience of passionate and empowered men and women. I broadened my skills of consensus and execution under constraint. I built unique connections upon the ideas and efforts of so many before me who generously gave their time and talent to help me to grow.

There are ways through the difficult and challenging obstacles that can make life difficult for business and enterprise architects. There are solutions. There are options. There are opportunities. It takes focus, dedication and passion to bring them to light. I was richly fortunate to have a chance to work with such a strong, vocal, and passionate team of people.

To sum this experience up, I’d like to share my recollection of the words of one of the attendees. At the closing, we spoke in turn about what we learned during the workshop and what we wanted to say to end it. One attendee shared this:

When I came to this workshop, to be honest, my expectations were very low. I had no faith that business architecture could achieve the goals that were being set for it. I just didn’t see it. Now, after these two days, I can see it. I feel like I learned 20 years of experience in two days. Thank you.

You are welcome.

How to Become a Hero for Growth

April 23, 2013 by Nick Malik

One thing that happens when you work to develop change across an organization: you detect the “cultural” elements of an organization that often go unnoticed by the people involved. Just as a “Fish discovers water last,” people working in a cultural context can be fairly unaware of the implications of their culturally influenced decisions. “It’s the way we’ve always done it, here.”

One cultural influence that I’ve seen, quite often, in organizations that are struggling to grow past a particular size, is the “culture of heroes.” This pattern of behavior has the following smells:

Whenever there is a problem with the servers, call Jack. While it isn’t his current job, he’s the one who installed and designed the server environment, so he’s the logical one to fix it. (Extend this beyond “the servers. For every “area” of the system or the business process, there is a “person” who is the “hero” who can solve problems with that area. There’s often an “uber-hero” above them all, who has to be called in for every emergency no matter what).
If someone asks me to do my job differently, I refuse until my manager specifically approves the individual change. After all, my manager has done this job for years and years, and he or she knows best how to do it.
If I’m a hero or a manager, and I make a casual remark in a meeting that I want to have control over some minor aspect of a process, a subtle but IMMEDIATE shift occurs so that the process now has an extra step: to ask me for my approval of that minor aspect (even if it is something that has little or nothing to do with my actual accountabilities).
If an important new project is starting, the kickoff meeting cannot proceed unless a couple of heroes are in the room. Absolutely no way.

These are signs of a culture of heroes.

And they are a big problem.

Let’s first recognize that, for any snapshot of 100 people in the same role, there are two or three that have risen up to become well respected experts. There are 20 or so that can lead a group, and the rest are following. One of those “folks in the rest” may mature, of course, and may be ready in the future to lead or become one of those well respected experts. These are not labels. But, at any one point in time, the ratios often work out this way.

This is human nature. Nothing wrong with that. The problem comes when you feed it.

As a leader, you cannot avoid a variation in skills and experience. However, the true leader recognizes that there are people who want to grow. He or she will want to create an intentional culture that not only fosters that growth, but encourages individuals who are the experts to “step aside” a little, and allow the non-experts to have a chance at solving tough problems.

If your culture keeps coming back to a handful of heroes, no one else in the team can grow. The people who naturally WANT to grow will leave. And you are left with an organization of people who don’t want to grow.

If no one in your organization wants to grow, the organization won’t grow. Plain and simple.

Not only that, your organization won’t evolve. It won’t improve. It won’t optimize. It won’t do ANYTHING interesting or new. That’s because all the people who could benefit by change, all the people who have fresh ideas and novel approaches and interesting influences, have run away to other organizations where they can try those ideas out.

And that is what the culture of heroes does… it kills the spark of change in a group of people.

So don’t let the heroes stunt the growth of your organization. Look around. If you have heroes who usually get called, ask THEM to be heroes in a different way… heroes for growth.

A hero for growth makes this decision:

I listen when someone brings me a problem.
I consider whether the person who has the problem should be empowered to solve it.
I consider whether the possibility of them “doing it wrong” means that they will cost a great deal of money or some other business loss.
Then, I take the DEFAULT position of “let the person closest to the decision make it.”
I only take on a challenge if the people who should be doing it are asking for my help. (Not their managers, or their peers, or their staff.) And when I do, I take the attitude that I want to help that person grow… so I challenge them, include them, and inspire them. When things work, they get credit. When things fail, I take part of the blame (giving them a safe space to grow). I don’t override them, belittle them, or ignore them. I never ever point fingers.

If you are a hero in your organization, I challenge you right here to become a hero for growth. Who knows… you may change your culture just by your leadership, and your example.

Unraveling the Developer Bias in Agile Development Practices

April 16, 2013 by Nick Malik

There is a contradiction that shows up in many books and articles on agile software development. . And I’m going to rant a little on one of them: the “developer” bias in Agile software practices.

Before I begin my rant, I’d like to tell you where it comes from. I am an Enterprise Architect. I am also an agilest. I am a certified Scrummaster (for many years) and have been on many agile projects. I’ve seen success, and I’ve seen failure. I know that agile is good, but not good enough to overcome people who are determined to undermine change.

I am currently engaged on a project to help an organization rewire their business processes. All of their core processes. Some of them are in software development… and that is where agile comes in, but some are in other areas (sales, account management, customer service, etc). I see it all, not just the software engineering bits.

To make this work, we created a set of principles that we use to drive the conversation around transforming the company. We train people on the principles. We connect change to the principles. The principles are developed from the agile mindset but are not the same as the ones traditionally tied to the agile manifesto.

One is focused heavily on the notion of an empowered team. As the trainer, I’ve embedded these principles into my head. Kinda hard not to. So when I’m reading a book on agile practices, and the author says something that violates one of these principles, it stands out. Big time.

And hence the rant. I was reading Mike Cohn’s book on agile stories and I came across a passage that reflects a kind of mindset that does NOT build empowered teams. And I went off. The rest of this post is my rant.

—

On one hand, there is a basic expectation that we should empower the team to solve their problems using their skills and training. On the other hand, there is a bias towards having developers involved in every part of a business process, from sales through requirements to project management and out to delivery and customer service. The net result: we are empowering developers to perform every role. No one else is empowered. They are, in fact, not trusted at all.

At some level, agile practices like XP and Scrum are written, and promoted, by software developers, so it is understandable that these authors believe that software developers are a necessary part of every process.

But they are not.

So what’s the problem

Organizations intentionally create specific roles and groups of people. Those roles are defined to take the most advantage of the intrinsic motivations of people when performing their duties. The things that motivate a person to become a project manager, for example, are rarely the same things that motivate a person to become a software engineer. Motivation matters. If you are not motivated to excellence, you will not perform with excellence.

While it is fine for an individual person to be able to perform well in a couple of roles, it is absurd to build a system or business process that expects all people in one role to be able to perform another role well. In specific, it is absurd to build processes where a technologist is required to develop requirements, or manage a project, or plan the delivery of systems. Those processes can be performed just fine with motivated people who are trained and experienced in those activities. However, to empower a team, people in these roles must be respected as well.

Agile software, that so values people over processes and tools, demonstrates an utter lack of respect for the individuals who choose to excel in non-technical roles by asserting the need for developers to be involved in every step of their process.

For example, in XP (and sometimes in Scrum), user stories are described as being developed by a “customer team” that includes developers. In the book “User Stories Applied,” Mike Cohn describes a process where a series of user roles are developed. From those roles, the stories will be drawn. The following is a quote from the book:

To identify user roles, the customer and as many of the developers as possible meet in a room with either a large table or a wall to which they can tape or pin cards. It’s always ideal to include the whole team for the user role modeling that initiates a project, but not necessary. As long as a reasonable representation of the developers is present along with the customer, you can have a successful session. — “User Stories Applied” by Mike Cohn

I’m an agilest, and this statement takes my breath away. Why? Because the SKILL of developing user roles is a good skill to have, but not a necessary skill for all developers to have. Yet the author (whom I respect) assumes that the activity cannot be performed successfully without developers in the room! At the same time, the text assumes that the task can be performed by developers exclusively (no one else is necessary at all).

The time that we spend training developers to be good at creating user stories is time that we are NOT spending training them on concurrent processing, idempotent messaging, and query optimization. We don’t train business analysts or engagement managers on C# design patterns, so why should we train developers on user role modeling and requirements analysis? It’s a total lack of understanding of the value of roles, and it is a bias that works against success.

What’s the solution: respect

Roles are not boundaries. In any team, there are roles. More importantly, as a member of a team, I have to trust my team members to fulfill their roles well. If they need help, I TRUST THEM TO ASK FOR HELP. When they do, I am happy to “cross roles” and provide help. When I provide help, I am doing so from the perspective of a less-skilled resource, and under the supervision of the accountable role. (e.g. if I “help” a tester, but don’t document a defect according to team standards, how much “help” am I actually providing?)

Roles are empowering. If my team member does not ask for help, I trust each one to perform his or her role with excellence. If I don’t trust them, how can they develop the excellence that the company expects? How can they be recognized and rewarded for excellence if our processes and methods show a lack of trust in their roles to perform well without a developer present?

Roles demonstrate respect. As an agilest, I value people over processes. That means I value the contribution of individual experts on my team to do their work with excellence, and I will show them respect for the work that they do, and the unique value that they contribute. I will do so by allowing them to do their work without the “supervision and assistance” of a developer.

If they need me, they will ask for me. Until then, I will get to doing what I do best. I have a job to do, after all… and it is mine to do well.

Why this matters

Agile software development solves a problem. The problem is that we are including waste in our processes, and that waste is causing software to be delivered late or with poor quality.

If we optimize our processes, we can reduce waste. If we include developers in every process, we are not optimizing our processes. We are, in fact, replacing one kind of waste with another.

Has in-person communication become the unwilling victim of technology?

April 8, 2013 by Nick Malik

In Enterprise Architecture, one of the most important aspects of the job is not only to communicate, but to lead change. In other words, it is great to have the data to point to a problem in an enterprise. It is better to help that enterprise overcome it by changing something (processes, technology, training, staff levels, departmental structures, roles and responsibilities, artifacts, governance mechanisms, etc). Change requires more than simple communication. It requires a kind of in-person, face-to-face, listening and hearing and absorbing interaction that is difficult or impossible over written mechanisms like e-mail, word documents, and powerpoint presentations.

Our technology has led us to the point, in modern business, that we consider outsourcing and remote work to be a net benefit for all involved, but each of these “distance” mechanisms introduces the RISK of poor communication. That risk is magnified when the person on one end of the line is hoping to change something that the person on the other end is doing. Change is harder across distance, and that difficulty becomes magnified when dealing with the array of different interactions that are needed at the enterprise level.

I wonder if the PC revolution, that brought us personal access to written communication, has created a deep reliance on written communication in corporate processes. I wonder, further, if that access to technology isn’t directly harming our ability to look a person in the eyes and communicate with them.

As a culture, we have moved from the age of face-to-face all the way to text-messaging-someone-in-the-same-room in the course of a single generation.

Enterprise Architecture is more difficult because of this shift in communication patterns. All forms of face-to-face communication are hampered by it.

Modern technology has done more to damage interpersonal communication than any other paradigm shift in human history.

This worries me.

AGILE architecture vs. agile ARCHITECTURE

April 5, 2013 by Nick Malik

As an architect involved in an agile implementation (my current gig), you can imagine how interested I was to see that there’s a new book on Agile Architecture, and perhaps how disappointed I was to see that it focused on SOA and Cloud. That’s not to put down SOA or the cloud. I’m a huge fan of both. But it wasn’t the area of agility that I was hoping that a book, with that title, would address. The misunderstanding was mine, not the authors. I haven’t read the book yet, but I’m sure I will.

That moment of misunderstanding crystallized a thought: how even a two word phrase like “agile architecture” had two completely different meanings. The opening scene of the movie “The Hobbit, An Unexpected Journey,” puts a rather humorous twist on this idea, when Gandalf introduces himself to Bilbo Baggins (who has apparently forgotten having met him as a boy).

Bilbo: Good Morning

Gandalf: What do you mean? Do you wish me a good morning, or mean that it is a good morning whether I want it or not;

Bilbo: <stunned silence>

Gandalf: Or that you feel good this morning; or that it is a morning to be good on?

Bilbo: All of them at once, I suppose.

Of course, in Enterprise Architecture, we have the same problem. Does Enterprise Architecture mean “the practice of using technology architecture at an enterprise-wide scale,” or does it mean “the practice of using architectural ideas to shape the enterprise itself?”

And after a bit of stunned silence, perhaps it means

“Creating an architecture to describe the externalities of an enterprise to set its context and improve the relationships it has with customers, partners, and suppliers?”

All of them at once, I suppose.

Having just re-watched the Hobbit movie on my morning flight, these bits connected up in my head.

I’m proud to be both an architect of agility (applying the principles of agility to the processes of a business so that the business achieves the ability to change its own processes in response to agile demands), as well as a person who can craft technology architecture that reflects the notion of agility itself (technology that can be set up to change rapidly in response to business events).

All of them at once, I suppose.

Humility and the Art of Enterprise Architecture

February 27, 2013 by Nick Malik

As a lot, Enterprise Architects are not terribly humble people. We name frameworks after ourselves, and sometimes go to great lengths to correct the “misinterpretations” of others who describe our work in a way that we don’t agree with.

Yet, recognizing that the field is young requires that we should be willing to change as the field of EA changes; that we should be willing to look back on our models, developed in the past, and admit that we missed a few steps that we wouldn’t miss today.

I recently had the opportunity to discuss, on LinkedIn, a blog post that I made five years ago. I look back on that blog post and must admit that my opinions are a bit different now than they were five years ago. I still agree with my post, but I would certainly use different words today than I used in the past. I am more than willing to admit it.

I also look at the efforts of Alexander Osterwalder whose Business Model Canvas has proved both practical and flawed. He missed the fact that he needed to create a differentiation between the customer’s needs and the value proposition of the business offering to fill some of those needs. Did he go back and create an updated canvas? Nope. He created a new canvas to describe demand as though it fits with his older one (hint: it’s a mess).

The venerable John Zachman, probably one of the most humble men I’ve met, also made this same mistake. While his original model was only a couple of columns, and was updated only a few years later into the table we see today, the field of EA has changed. The table is no longer representative of companies with multiple business models (most of them) and the lack of a “customer” row simply relegates his “ontological table” to the dust bin.

Neither man will change. They have “legacy” models, with their names attached. To paraphrase Forrest Gump, humble is as humble does.

I would like to think that my willingness to upend my EBMM and replace it periodically with new versions shows my willingness to admit that (a) I’m often wrong, and (b) I’d rather learn than become stale. That said, I’m no paradigm of humility, myself.

After all, a truly humble EA would not have written this blog post.

(As my teenage daughter would say: Oh snap, you pwned yourself!)

Should Business Architects use the Business Model Canvas at the Program level?

January 31, 2013 by Nick Malik

In the Open Group conference at Newport Beach, I listened to a series of presentations on business architecture. In one of them, the presenter described his practice of using Osterwalder’s Business Model Canvas to create a model of his program’s environment after a business program (aka business initiative) is started. He felt that the canvas is useful for creating a clear picture of the business impacts on a program. There are problems with this method, which I’d like to share in this post.

Let me lay out the context for the sake of this post since there is no business architecture “standard vocabulary.”

A “business program” is chartered by an “enterprise” to improve a series of “capabilities” in order to achieve a specific and measurable business “goal.” This business program has a management structure and is ultimately provided funding for a series of “projects.” The business architect involved in this program creates a “roadmap” of the projects and to rationalizes the capability improvements across those projects and between his program and other programs.

For folks who follow my discussions in the Enterprise Business Motivation Model, I use the term “initiative” in that model. I’m using the term “program” for this post because the Open Group presenter used the word “program.” Note that the presentation was made at an Open Group conference but it does NOT represent the opinion or position of the Open Group and is not part of the TOGAF or other deliverables of the Open Group.

The practice presented by this talk is troubling to me. As described, the practice that this presenter provided goes like this: Within the context of the program, the business architect would pull up a blank copy of the business model canvas and sit with his or her executive sponsor or steering committee to fill it out. By doing so, he or she would understand “the” business model that impacts the program.

During the Q&A period I asked about a scenario that I would expect to be quite commonplace: what if the initiative serves and supports multiple business models? The presenter said, in effect, “we only create one canvas.” My jaw dropped.

A screwdriver makes a lousy hammer but it can sometimes work. The wrong tool for the job doesn’t always fail, but it will fail often enough to indicate, to the wise, that a better tool should be found.

The Osterwalder’s business model canvas makes a very poor tool for capturing business forces from the perspective of a program. First off, programs are transitory, while business models are not. The notion of a business model is a mechanism for capturing how a LINE OF BUSINESS makes money independent of other concerns and other lines of business. Long before there is a program, and long after the program is over, there are business models, and the canvas is a reasonable mechanism for capturing one such model at a time. It is completely inappropriate for capturing two different models on a single canvas. Every example of a business model, as described both in Osterwalder’s book and on his web site, specifically describe a single business model within an enterprise.

I have no problem with using business models (although my canvas is different from Osterwalder’s). That said, I recommend a different practice: If the business initiative is doing work that will impact MULTIPLE business models, it is imperative that ALL of those business models are captured in their own canvas. The session speaker specifically rejected this idea. I don’t think he is a bad person. I think he has been hammering nails with a screwdriver. (He was young).

Here’s where he made his mistake:

In the oversimplified value stream model above, Contoso airlines has three business models. The business owners for these three businesses are on the left: Bradley, Janet, and Franklin. Each are primarily concerned with their own business flows. In this oversimplified situation, there are only two programs, each with one project. If the session speaker were working on the Plantheon program, his idea works. there is only one business model to create. That nail can be hammered in with a screwdriver. Lucky speaker. Showing Franklin his own business model is a good thing.

But if we are working on the Flitrack program, what do we show Franklin? if we create a “generic” canvas that includes cargo, he will not recognize the model as being applicable to his concerns. He will not benefit and neither will the program. In fact, Franklin will think us fools because he had a presentation from Plantheon yesterday showing him an accurate model… don’t you people talk?

Program Flitrack should have one-on-one conversations with Bradley and Janet to develop their business models. The business model that Franklin cares about does not need to be created again. It can come out of the repository. The Flitrack program would consider all three models as independent inputs to the business architecture of the organization impacting the program.

Anything less is business analysis, not business architecture.

Rumination on the concept of “best practice”

January 29, 2013 by Nick Malik

I heard some very interesting talks today from Len Fehskens and Jeff Scott at the Open Group conference. One thing that I picked up in a meeting yesterday was the notion that TOGAF 9.1 is built on “best practices.” Today, as Jeff spoke about the transformation of a technical architect into a business architect, and as Len spoke about the challenges of communicating complex ideas, the notion of a “best practice” kept bothering me, and I cross-pollinated my concerns with the concepts that they were sharing.

I agree that the intent of the people who shared their practices with the Open Group was to provide practices that can be taught and followed. I even agree that the people on the TOGAF committees that accepted the content felt that the practices represented the best that the industry had to offer at the time. But I wonder if any of the work done in framework committees of any stripe (not to pick on the Open Group) can be held to the standard of being a “best practice.”

Are the practices in the TOGAF framework truly “best�� practices? Are these practices the best ones that the EA field has to offer?

I guess I would have to follow the EA rabbit hole and ask “what criteria do we use to judge if a practice is the best one?”

After all, when Jeff Scott talks about business architecture using capability modeling, he believes that the practice of capability modeling is the best one to use for the results he is trying to achieve. (I nearly always agree with Jeff, BTW. We sometimes differ in language, but nearly never in approach). That said, as much as Jeff and I agree, our agreement does not mean that the practice should be considered a “best” practice. Who are we to say? We are practitioners. While that is good, it is not enough in my mind to qualify the practice as “best.”

To be a best practice, in my opinion, a method or approach has to meet a higher bar. There has to be evidence that it is, in fact, better than just a “good practice.”

I think a best practice should have:

Some measurement (evidence) that demonstrates that it is an effective practice, and that the measurement shows that it is at least as effective as other practices,
A clear understanding of the results of the practice and the context in which it is to be performed (think “Pattern Language” criteria),
Some analysis to show that it meets other criteria like broad applicability and simplicity, and
We should demonstrate the ability for that practice to be understood and performed by people who are currently in the role (e.g. can we teach it, and if we teach it, can others do it?).

I wonder if we went through most of our frameworks and highlighted the text that is able to meet a higher bar, like the one I describe, how much of the text would we cover? 2%? 10%?

Is 10% coverage enough to say that a framework is based on best practices?

All Effective Enterprise Architects Are Agile

January 15, 2013 by Nick Malik

I explained to one of my clients recently that there is a perception of animosity between the Enterprise Architecture community and the Agile community. Both sides make assumptions about the other, often assumptions that are simply unfair. For example, many in the EA community think of “agile practices” as an opportunity to develop software without any architecture at all, while many in the agile software development community think of architecture as one of the “big design up front” guys who oppose their principles and practices. Of course, it is not difficult to find people who fit those unfair descriptions, but I’d like to point out how these two viewpoints are similar.

I believe that effective Enterprise Architecture must be approached from an agile standpoint.

First off, what does it mean to be agile? We can always look to the agile manifesto for some guidance, but more recent publications do a good job of filling in some of the details as well. I include a number of things in the notion of “being agile.” These are not just from the agile manifesto, but also Kanban and the Theory of Constraints, Systems Thinking, Six Sigma, Scrum, eXtreme Programming, and value stream analysis.

A focus on performing high-value activities, and removing low-value activities.
A focus on empowering the people who make things to make decisions about how those things should be made.
A focus on developing small increments of actual value on a frequent basis and getting direct feedback on them.
A focus on making sure that one thing is “done” before moving to the next, so that we reduce “debt” as we go.
A focus on modern practices that remove ‘deployment impedance’ like test driven development and continuous integration.

I follow the terminology of Sam Guckenheimer in calling this the “Agile Consensus.”

We have to recognize that the “agile consensus” is an approach, not a methodology. It is a way of thinking about dealing with problems. More importantly, it is a way for dealing with complex problems. The diagram below comes from Ken Schwaber (inventor of Scrum) who adapted it from Strategic Management and Organisational Dynamics, by Ralph D. Stacey.

When we look at the problems that software is being used to address, and if we look at the process of writing software itself, we have to recognize that both areas of problems typically fall into the category of “complex.” Not always. Some software is simply configured and configured simply. Some problems that software addresses are simple problems. However, most of the discussions around software development are fueled by people addressing complex problems because that is where most of the software development community works. It is the bread and butter of software development: solving complex problems in a complex way.

Enterprise architecture also deals with complex problems. EA models and information are also complex to build and manage. In this way, EA is very similar to software development. EA solves complex problems in a complex way.

In order for EA to be effective, it has to use the same mentality as agile software development.

When I speak with enterprise architects who are actually doing the job of EA, big themes quickly arise:

do the work that is highly valuable and don’t do the work that the business doesn’t value
build consensus where it actually lives, not where the “people from above” believe that it does
deliver value quickly and in increments that your stakeholders understand
leave your repository in a good state of completeness with all the data that others need to use it
build in the deliverable artifacts into the business processes that need it, so that you get immediate feedback

If this looks like the list above, that is intentional. I am trying to point out that Enterprise Architects use agile ideas, even if they often don’t use the term “agile” to convey the message.

Why use these techniques? They work for complex problems.

Can someone think of a more complex problem than helping to move an organization towards their goals?

EA addressed complex problems. Agile thinking helps them to do it.

The most important personality trait of an Enterprise Architect

January 10, 2013 by Nick Malik

The video below, from RSA Animate, is not about Enterprise Architecture. At least, on the surface, it isn’t. In the video, we hear the voice of Roman Krznaric, a philosopher, talk about the need to build a greater reliance on the human emotion of empathy in order to create social change.

But as an Enterprise Architect, I am in the business of creating social change. I’m actually paid to get things to change (how’s THAT for a cool job). Of course, I’m paid to make the changes within corporations, and the benefit goes to the corporation by making them more effective, efficient, or timely in their desire to “make tangible” their own business strategy. However, the reasons and rationale aside, my job is all about change. And people do change, but not easily and not quickly.

There are many reasons that people don’t change. My father used to say “the hardest thing for a person to do is to think. The second hardest thing is to change. So if you want them to think, don’t ask them to change, and if you want them to change, don’t ask them to think.” Oh, there’s truth in there. You cannot get people to change simply by “convincing” them to do it. There has to be more to it, and there is. But to understand how to motivate change, it helps to start with a little thought experiment.

Think about the times when you changed. Seriously… stop right now and think about your own changes. Have you ever changed a core belief? Have you ever converted to a religion, or away from one? Have you decided to change your profession or career? Have you ever decided that the things that you always assumed were now completely untrue? Think about family members that changed?

Did you change because someone asked you to think? Or did you change because someone asked you to feel? What led the way?

I am convinced that the only EFFECTIVE way to motivate change is to reach out and touch someone emotionally. You can bring them along with logic, but if you don��t find their heart, and connect with their feelings, they won’t feel your message. Notice, I didn’t say that they won’t hear your message. They can hear just fine… but without connection, they won’t feel your message. And if they don’t feel your message, they won’t follow your lead.

We have often heard that change is about leadership. But how does a leader lead? Is it through logic and elegant words, or is it through emotion and beautiful thoughts? The most effective way to lead is to use both, but if you have to use one, use the emotional side first. In Switch, How to change things when change is hard, authors Chip and Dan Heath argue that you have to engage both the logical side and the emotional side to want to change. However, their metaphor is one of a person riding an elephant. The logical side is the rider. The emotional side is the elephant. Why, in their metaphor, did they choose an elephant? Because the emotional side is much larger than the logical side, and we can viscerally understand the metaphor on the basis of size and strength alone. After all, if the elephant wants to turn around, the rider can do little to stop him.

In Switch, the Heath brothers argue that change is an emotional journey and that there are three parts: the elephant, the rider, and the path. If the path makes sense to both the elephant and the rider, then you have removed the obstacles to change. Make it a clear path. Appeal to the rider to want to take it. Appeal to the elephant by addressing the fear or uncertainty that may drive them away from it. That is the job of the EA. To make a clear path, and to make it so that it starts where the elephant is actually standing at the moment.

So as an Enterprise Architect, how do I find a way to communicate with the Elephant and the Rider in the people that I want to work with? I use empathy. I don’t just use empathy… I live it. Empathy is the single most powerful, most important, and most useful personality trait that an Enterprise Architect can have, bar none. It is a skill that must be practiced, and learned, and honed. It is more than listening, but listening is involved. It is more than feeling, but feeling is involved. It is connecting at a deep level with the people that you are being asked to work with. It is building an empathic bond with them.

Philosopher and author Roman Krznaric explains how we can help drive social change by stepping outside ourselves.

Having a strong sense of empathy means that the EA has a strong internal drive to connect with others. He or she wants to hear their stories, and learn their troubles, and feel their triumphs, because ONLY by connecting with another individual can an EA understand what is motivating that person to change, and what is keeping them from achieving it. Only by listening to their struggles, and their successes, and their own efforts, can the EA create a path for that “emotional elephant” that Chip and Dan Heath describe. Because the job of the EA is to create the path. The job of the leader is to connect with the elephant to bring them down the path.

Some people motivate others through fear. Do this or you will lose your job. Do that or the company will go under (and you will lose your job). Do this other thing or we will cut your bonus or give you an assignment that you will hate. Some will motivate through rewards and recognition. “Look at what Tom did! He delivered excellent results and we want to honor him. You can be honored if you do as well as Tom.” In our capitalist society, that may even be in the form of income: “Your bonus will be larger if you do a better job.” (Both of these approaches fail, by the way. True story. Watch this TED video of Dan Pink’s presentation on motivation).

In order to motivate change, especially in creative jobs, you have to make it easy for the elephant (the emotional side) and the rider (the logical side) to follow the path from where they are to where they need to be. Notice that the path doesn’t start from where you think they are, or where a company thinks their employees should be. It starts from where they actually are. Without empathy, you may build the perfect “path” but it may start in the wrong place… where the elephant is not actually standing!

Empathy also helps you to connect with the person who you want to change, and to discover their intrinsic motivators. As Dan Pink points out in the TED video I linked above, the most important motivators are intrinsic. They are internal. They are not the incentives offered by the business. They are the things that a creative, thinking person already wants: Autonomy, Mastery, and Purpose.

Autonomy – the desire to direct our own lives,
Mastery – the desire to get better and better at something that matters, and
Purpose – the yearning to serve a greater goal.

If an EA wants people to change, that EA has to engage that emotional elephant and that logical rider. To give people the autonomy that they need, and to demonstrate the mastery that they can achieve, and to give them a purpose to follow, in the world of control, incentives, and finance that the business lives in, you have to first listen and connect and understand. That requires empathy.