I get many questions about demonstrating the value of business architecture but a few weeks ago I was in a discussion with some fellow business architects who had a more specific question, “What is the value of a roadmap?” After thinking about this a while, I came to the conclusion that we often miss the […]
Have you seen practices that you know could kill an Enterprise Architecture practice? I have. A recent LinkedIn thread asked for examples, and I came up with my top ten. I’d love to hear your additions to the list.
How to screw up an EA practice
- Get a senior leader to ask for EA without any idea of what he is going to get for it. If necessary, lie. Tell leaders that EA will improve their agility or reduce complexity without telling them that THEY and THEIR BUSINESS will have to change.
- Set no goals. Allow individual architects to find their own architecture opportunities and to do them any way they want. Encourage cowboy architecture.
- Buy a tool first. Tell everyone that they need to wait for results until the tool is implemented and all the integration is complete.
- Get everyone trained on a “shell framework” like Zachman. Then tell your stakeholders that using the framework will provide immediate benefits.
- Work with stakeholders to make sure that your EA’s are involved in their processes without any clear idea of what the EA is supposed to do there. Just toss ’em in and let them float.
- Delete all the data from your tool. Give no one any reason why. You were just having a bad hair day.
- Get in front of the most senior people you can, and when you get there, tell them how badly they do strategic planning.
- Change your offerings every four months. Each time, only share the new set of architectural services with about 20% of your stakeholders.
- Create a conceptual model of the enterprise that uses terms that no one in the enterprise uses. Refer to well known business thinkers as sources. When people complain, tell them that they are wrong. Never allow aliases.
- Every time you touch an IT project, slow it down. Occasionally throw a fit and stop an IT project just for fun. Escalate as high as you can every time. Win your battles at all costs.
Your career will be short. 🙂
When I was a relatively new manager, I would occasionally get into disagreements with my peers. My CIO would call me into his office and tell me I should go fix the relationship. Being the good employee, I saluted and said, “Yes sir.” The third time this happened I pushed back. “Why are you always […]
The big problem is that today Business (Enterprise) Architecture practices exist without ever creating business blueprints.
Most of today’s business architecture initiatives are struggling to gain a sound footing in their organization. Part of the challenge is the immaturity of the business architecture profession and a lack of exposure in the business literature. However, architects are often part of the problem too, trying to implement the theory too explicitly. At Accelare, […]
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.
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?
Organizations today expect much more innovation from their employees than they did yesterday and will expect even more tomorrow. And not just technology innovation, but innovative products, services, processes, strategies, leadership styles, organizational designs, and more. This means that innovation isn’t just another function we can bolt on to our current role. It is a […]
If you are an established business architect you are most likely already doing most of these items. But if you are new to business architecture or are coming from IT or other operationally focused organizations, you should give each of these steps serious consideration. Spend more time with business leaders. You don’t have to corner […]
Jim Hietala, vice president of security at The Open Group; Thomas Hardjono, technical lead and executive director of the MIT Kerberos Consortium; and Dazza Greenwood, president of the CIVICS.com consultancy and lecturer at the MIT Media Lab explore how…
NOTE: When I refer to “Business Architects” here, I am referring to anyone playing the role of the business architect. This could be business managers, enterprise architects, business analysts, strategists, etc. We don’t need the title of business architect to be one. When we do “business architecture things” we are acting as business architects. There […]
By Sally Long, The Open Group Globalization has transformed the supply chain forever. While it has brought benefits to large Commercial Off-the-Shelf (COTS) Information and Communication Technology (ICT), it has also brought considerable risk. Although…