Archive for the ‘Management’ Category
On the Forrester Enterprise Architecture Community site, Randy Heffner asked the question, “What should EA do for business agility?” In my two responses in the discussion, I emphasized that EA is all about decision support. Yes, you may create a future state roadmap, but what the organization winds up with is completely dependent on what projects the organization decides to execute, and then on how those efforts are executed. EA influences those decisions, but we’re not the ones making them.
So why is this post titled, “Deciding ‘Yes’ on EA”? In that same discussion, William El Kaim added the following:
Let me be real provocative, and state: EA is dead … It has been killed by architect themselves leaving in their ivory tower and their beautiful EA drawing tool that nobody uses and that contains outdated data when they are published.
You can read the rest of what William had to say on the Forrester site, but I don’t think it’s anything any of us practicing EA’s haven’t heard before. But there’s a very important point in William’s statement. If nobody uses what EA produces but EA themselves, that’s a big problem. Put simply, if we provide poor decision support, the organization will ultimately decide against EA.
Like most things in this world, there are far more ways to fail than there are to succeed. So what are some best practices for providing excellent decision support so that the organization will decide “yes” on EA?
- Figure out who makes the decisions. Sounds simple, right? Not quite. I’d love to see a Forrester or Gartner survey on this one, but I’m willing to clarity and consistency on the decision making process is not a strength for most organizations. Regardless of the state of your decision making process, if you don’t have access to the people making the decisions, you have little to no chance of influencing them.
- Figure out how they make their decisions. Note that I didn’t add, “and make them better.” Remember that they’re the one making the decisions, not you. Your role is to give them added information so that they can make the best decisions possible. In some cases, the whole reason for having the discussion may be so you can learn and incorporate that decision maker’s information into your guidance for other decision makers.
- Make your information relevant to them. Don’t give them a bunch of models that are only meaningful to another EA. In the case of upward decisions, this usually means that the architecture implications have to have financial ties, or clearly alignment with business objectives. I’ve had success using capabilities in these discussions, and I think the current research would back that up. You must tailor your information to their needs. If they don’t understand it, it’s your problem, not theirs. They’re making the decision, not you.
- Emphasize added insight, not oversight. This is very important for interactions with project teams. All too often, EA is positioned as the enforcer. Come before the review board and we shall assess your worthiness. I’m sorry, but a guy who spends 80% of his time writing code each day should be far more aware of the latest frameworks than the average EA. The role of the EA is bring enterprise and/or domain perspective to the effort. As soon as the project gets established, the project blinders go up, and it’s the job of EA to remove those blinders and add enterprise insight into the effort.
- Don’t rely solely on artifacts, and where you must, make sure they are easily digestible. While many factors in an organization lead us toward email-based interactions of documents, try to have a face-to-face conversation about the guidance whenever possible. At a minimum, by walking someone through it, you at least knowing they’re actually reading some part of it. When you create the artifacts, get them to the point.
- Be cautious about consulting models for EA.A consulting model for EA is great, right? When someone needs more information to make a decision, what do they do? They hire a consultant. So EA should be internal consultants, right? Well, not really. That may work in the short term, but it is a “I’m here when you need me” model, when you really want to always be a part of the process. Don’t turn down the consulting approach, as it can get your foot in the door, but make sure you turn it to something more systemic.
What other best practices (or worst practices) do you recommend in firmly establishing EA as a valuable resource in the decision making processes in the organization?
Every organization has one. For some, it can lead directly to a path of enlightenment. Others may use its rigid structure to create an impenetrable fortress of strength. For the unfortunate, it becomes an inescapable labyrinth of hopelessness. Yes, it’s the org chart.
Okay, let’s be fair, it’s actually not the chart that’s the real challenge, it’s the organizational structure. Any organizational structure creates boundaries, and those boundaries create opportunity for divergence, whether in strategy, opinions, processes, or just about anything else. The challenge is figuring out how to structure the organization to diverge where you need divergence, but to be consistent where you want consistency. It’s no surprise that organizational structure is considered by some to be part of the enterprise architecture. Just as we try to organize our technology portfolio in the best manner to achieve the desired business goals, we need to organize our human resources as well. More importantly, just as management may choose to reorganize its human resources as the business goals and operating context changes, the way we organize our technology portfolio needs to change as well.
The organizational structure poses a particular challenge for the practice of architecture, particularly when it comes to solution architecture. I’ve seen at least three different models for organizing the architecture practice. First, is the centralized model where all architects report up to a single Chief Architect or Director of Architecture. There may be some middle management in there, but there is always a solid line leading to the top. As you might guess, this usually leads to a high degree of consistency, but can have challenges in scaling to meet demand, retaining business domain knowledge, and of course, ensuring that the centralized resources actually get used by projects and avoiding “rogue architecture.” The overuse of the term “architect” in job titles these days makes this even more problematic, as senior or lead developers may now have the title of Java/.NET Architect. It may also create delays in decision making, because the solution delivery has one reporting structure, while the solution architecture has a different reporting structure. If there is a disagreement, these two management structures must come together to resolve the difference, or it must be escalated up the chain.
A second model is a separation of the Enterprise Architecture function from the Solution Architecture function. Enterprise Architects have a solid line to the Chief Architect/Director of Architecture, Solution Architects report through a different structure, perhaps having a dotted line back into the EA organization in a matrixed structure. Consistency becomes more of a challenge, because Solution Architects will likely receive more direction from their management structure than from the EA team. It also creates challenges for the EA function, because now the EA team is at risk of being completely disconnected from solution delivery. Even in the centralized model, the bulk of the input into the solution comes from the solution management side of things. Now, that push will be even stronger, with architectural management struggling to maintain a voice. That voice is sometimes mandated through an architectural review board, but if that’s the only time that architectural management has the solution architect’s ear, the effort is likely to struggle with EA being seen as an ivory tower, rather than a necessary contributor to solution success. I’ve seen this model more than either of the others, however.
The third model would be the completely decentralized model. In this case, there is still a practice of architecture in the organization, but it is completely distributed. Solution architects, and perhaps domain architects, are scattered throughout the organization. A virtual team may exist, and there may even be a Chief Architect/Director of Architecture, but the role may largely be one of information sharing and coordination, and not really about architecture management. What’s good is that there’s not much risk of being perceived as an ivory tower, but there is significant risk of poor architectural alignment. If the boundaries of diversification are based upon an assumption that business units do not share customers, what happens if the situation changes and they do? Even ignoring the potential for this situation, decisions on centralization versus a matrixed approach are likely made locally within each business unit.
So what model is right? First, a completely decentralized approach is really only suitable for companies with a completely diversified operating model (see this book if you don’t know what that means). So, it really comes down to centralized versus matrixed, and that will either be applied at the business unit level for a diversified company, or at the enterprise level for other operating models. Both centralized and matrixed can work, but there is a catch. I’ve used the term “architecture management” in this blog. As I wrote this, I kept thinking about parallels to project management and a PMO. I’ve seen centralized PMOs where all project managers report into a single organizational group, and I’ve seen decentralized PMOs where individual project managers report into lines of business while a core group of resources that look at things from a portfolio perspective report into a Director of Product Management. The catch is consistency. If each project manager did things their own way, it is going to be extremely difficult for anyone to manage things at a portfolio level. Without establishing some minimum level of consistency that produces the necessary metrics and information at the right times for portfolio level management to happen, you’re sunk. Fortunately, for project management, the need for this is a well accepted practice. No one wants to wait to find out that a project is $100M over budget until after it happens. If you have that consistency, you can make either model work.
In the case of architecture management, things are still maturing. The problem is that we are at risk of focusing solely on consistency, without properly understanding the outcome that consistency is supposed to create. While finding out that you’re $100M over budget after it’s been spent is well understood as a bad thing, is finding out that someone has built a component that already existed elsewhere in the company a bad thing? Not necessarily. Those decisions need to be made in the context of both the project’s goals and the enterprise’s goals to make that distinction. Pursuing enterprise consistency when there are only project goals involved in decision making puts you at risk of being perceived as an ivory tower. At the same time, it may be necessary to pursue some base level of consistency prior to establishing that enterprise context, otherwise the context may be perceived as irrelevant. This can happen when the practice of solution architecture really isn’t being practiced at all.
My final advice is this: a centralized path will definitely lead to the most consistency, but you have to be rock solid in your justification of the need for an enterprise viewpoint, because that centralized model creates management overhead, risk of resource availability, and the potential for conflicting direction. A decentralized model is at less risk of having resource availability issues, but makes consistency more difficult and is more prone to sacrificing enterprise direction for project delivery. Ultimately, it will come down to whether your organization has been successful with matrix management approaches or not. If it has, you should be able to make a decentralized approach work. If you’ve never been successful with matrix management, then a centralized approach will likely be necessary. Finally, if you go with a decentralized approach, but have very inconsistent architecture practices, I strongly recommend that you establish an architecture mentoring/facilitator practice. In this, members of the centralized EA team facilitate one or two day architectural workshops. This can ensure that things are done in a consistent manner, the voice of the enterprise is brought into the solution architecture process, but the risks associated with a completely centralized model are mitigated.
I’ve been doing some work recently on architecture principles and their associated implications. According to TOGAF 9’s documentation on architecture principles, implications “should highlight the requirements, both for the business and IT, for carrying out the principle – in terms of resources, costs, and activities/tasks. … The impact to the business and consequences of adopting a principle should be clearly stated.”
In the effort to define our implications, I’ve started to see two categories of implications emerge. The first is behavioral implications. These implications are functions or processes that the organization must adopt. The second is architecture/design implications. To illustrate this, use a very simple principle: standards-based. The statement for this principle merely states that all solutions must be compliant with company standards. A behavioral implications for this is that someone in the company must maintain a list of company standards. Another behavioral standard may be that the company must follow the work of standards organizations relevant to the business. An architecture/design implication would be that messaging interfaces must adhere to published company standards.
I’m finding that it may be worthwhile to explicitly define these categories in documenting the principles. One big reason is to avoid overemphasizing the architecture/design implications. It is very easy to strictly think of implications as the foundation for your assessment framework, but an assessment framework, in my experience, is typically associated with architecture and design reviews. It says nothing about reviewing the behavior of the organization, which all too frequently can be the greater challenge. For example, a reusable service may exist, but it doesn’t get used because the organization “supporting” it may see supporting other consumers as a secondary priority, at best. This isn’t a design issue, it’s a behavioral issue.
One additional thing I’m also considering is how to assess whether or not the thinking behind the implications is correct. If the rationale for a principle is that total cost of ownership will be lower, are we actually measuring whether this winds up being the case based upon our level of adherence to principles and their implications?
How would you categorize your implications? Does this two category breakdown make sense, or are there additional categories needed?
I recently completed reading the book Troux Enterprise Architecture Solutions by Richard Reese. First, the disclosure: this book was provided to me by Packt Publishing for the explicit purpose of this review. In addition, Packt is also the publisher of my own book, SOA Governance. I have no relationship with Troux, however, I have had discussions with various sales staff from Troux over the course of my career. This post is a review of the book, not a review of Troux.
First off, the book is well-written. I never felt like I was slogging through inordinate amounts of text, the chapters were of an appropriate length, and the level of detail was consistent throughout the book. Not including the index, it’s just shy of 200 pages and was a very easy read.
As a book on Enterprise Architecture, I found chapters 1-5 and 11 to be the most valuable. These chapters focused on managing the IT portfolio, creating strategic alignment, optimizing the application portfolio, IT governance, managing the EA practice (roles & responsibilities), and generating value. If you are new to Enterprise Architecture and need some ideas on how an EA program can contribute value to your organization, read these chapters. Chapters 6-10 are more focused on describing aspects of the Troux platform, with lesser emphasis on the practice of Enterprise Architecture. These chapters discuss architecture modeling, transformation platform, metadata management, visualization, and TOGAF support. Finally, chapter 12 is a summary, but I have to call out that it had one odd section on EA and cloud computing. This seemed out of place, and frankly, unnecessary. It felt like someone said, “Cloud Computing is the hot topic today, you have to say something about it.”
In terms of covering the Troux platform, it is important to know that this is not a how-to book. It is an overview of the platform. The right audience for this book are people that are looking to establish or mature their EA program and people that are considering investing in EA or Strategic IT Planning technology. For a $40 investment, this book provides excellent insight into the Troux platform. When you consider the time and money spent in vendor selections, this book is a very small price to pay to give you a great idea of what Troux can do, without any sales pressure. Having participated in many different product evaluations over the course of my career, I’m surprised more companies have not taken the approach of writing a very easy to read book targeted at the people that are considering asking for budget dollars or performing evaluations. Getting back to the content of the chapters, from my perspective, I preferred the more EA practice focused chapters with mentions of how Troux fits in over the chapters that were more focused on the platform (6-11), but my area of interest is the practice of EA. For someone who has concerns about whether Troux itself will work with the architecture methodology or be able to share information with other systems, such as a CMS/CMDB, these chapters cover those topics. It is good that the author covered both areas, as not all readers will have the same objectives for the book.
Summing it up, would I recommend this book? Yes. While the target audience is a bit narrow, for that audience, I think the book is quite valuable. Its appeal is not limited to people solely interested in the the Troux platform or EA technologies, as I think it has value for people interested in either establishing or maturing their EA practice. Some of the other books I’ve read on EA tend to be very academic in nature, this book doesn’t fall into that category. Instead, the coverage on the practice of EA was very pragmatic, even if though it does portray a very mature, structured IT organization. If you’re trying to determine whether EA or strategic IT planning technology is right for your organization, I would definitely read this book before jumping into vendor discussions, evaluations, and POCs.
There was a great discussion on Twitter today regarding influence, mandates, and leadership. My interest started with a tweet from Chris Venable, directed at Burton Group/Gartner EA analyst, Mike Rollings:
If EA is so important, why must it do everything through influence? No one ever says that to the CIO…
I thought this was a great question, and after retweeting it, a debate ensued around influence, mandates, and leadership among myself, Mike, Philip Allega of Gartner, Chris Lockhart, and others. In a nutshell, the question is this: Is it possible to be an effective leader without mandates?
My gut answer to this is yes, and I even feel that issuing mandates puts you at risk of being ineffective. As I dug into this, however, I realized that it’s not about the term mandate, it’s about the approach you take to providing leadership. Why is that the case? Look at the definitions for mandate, direction, and guidance, courtesy of thefreedictionary.com.
Mandate: An authoritative command or instruction
Direction: An authoritative indication; an order or command
Guidance: Leadership, instruction, or direction
I don’t see a big difference, do you? Yet, I’m sure we’d all agree that those terms are perceived very differently. Would you rather work for a manager that gave you direction or issued you a mandate? According to the dictionary, it’s really one and the same. Now look at influence:
Influence: A power affecting a person, thing, or course of events, especially one that operates without any direct or apparent effort.
The definition for influence actually mentions the word “power” which could be perceived as a negative, but more importantly, it goes on to state that we use the term more frequently when the power is imperceptible. This is where the difference lies. If mandate and direction mean the same thing, the real difference is when the leader can give that direction and influence the outcomes of the company without pushing so hard that it is perceived as something out of the ordinary at the time it happens.
An arbitrary mandate is like a shove in the back. It will be noticed, and it will be perceived in a negative manner. A justified mandate can be equally jarring, but can be acceptable in the short term. “I shoved you to the side so you wouldn’t walk into the huge pit of snakes that was in front of you because you were looking elsewhere.” The problem with both of these is that they’re “in the nick of time” decisions, and have to be jarring because there’s no other choice. The natural question then, is how did we get here in the first place?
This is where true leadership comes into play. Leadership is about setting people up to be successful from the beginning. That doesn’t mean that course corrections might be needed, but you set expectations early. How many of you have had an architecture review, or even worse, a performance review, where you were criticized for something you didn’t even know was expected? That’s bad leadership. Set the expectations and give people a chance to be successful. In setting the expectations, it must first be about the desired effect (note that nearly all the definitions for influence include either the word affect or effect) and not about the means. If it’s solely about the means, it becomes an arbitrary mandate. For example, “The desired effect is that our IT operational costs go down by 10%. We’re going to do that by consolidating redundant systems for X, Y, and Z.” rather than simply saying, “Everyone’s going to have to use system X from now on.” By not disclosing the desired effect, people will resist the change. By leading with the desired effect, you can also create an opportunity for people to come forward with alternatives. Where the effect is hidden, decisions become arbitrary or personality-driven, rather than outcome driven (see this post).
In a nutshell, set the desired outcome, establish a direction to achieve it, make course corrections as needed with an imperceptible gentle nudge so that it won’t be perceived as a mandate. That’s an example of influence, and that’s an example of leadership.
A key to any Enterprise Architecture program is solution architecture. Solution architecture is where work gets done. If your EA team is disconnected from the solution architecture effort, you’ll probably hear the term “ivory tower” a lot. Unfortunately, it’s far more common than you may think.
Looking the typical project, the first question is where do the solution architects report? Since many times they have grown out of senior development roles, odds are they don’t report into the enterprise architecture organization. On top of that, the key authority figure (decision-maker) within the project structure is typically not an Enterprise Architect, and it’s not even the solution architect’s manager. It’s the project manager and the project sponsor. This leaves a whole bunch of people that need to be influenced. They are:
- The Solution Architect
- The Solution Architect’s Manager
- The Solution Sponsor
- The Project Manager
The Solution Architect. The solution architect is going to get pulled in different ways. I believe that it is the job of Enterprise Architecture to make the solution architect’s life easier, rather than more difficult. If you’re just another voice pulling them in a different direction, it’s not a good situation. Think of yourself as a mentor to the solution architect, and provide them with the tools they need to do their job. Those tools are excellent reference material in the form of standards, guidelines, and patterns, pointers to the right people to talk to, a sounding board for options, and another set of eyes for reviewing work. On top of that, you should consider whether or not solution architects should report into the EA organization, or at least have dotted line reporting structures into EA. Which leads to…
The Solution Architect’s Manager. Assuming solution architects don’t report into EA, someone else is writing their performance review, and odds are, they’re getting judged not on the quality of their architecture but on their ability to deliver. They should be judged on both, and it’s up to the Enterprise Architecture team to work with the solution architect’s manager to ensure their performance objective include architectural objectives. If you don’t, architecture is likely to lose when push comes to shove. Also, keep in mind that you need to have regular conversations with the managers of the solution architects. Odds are they have regular conversations with their business stakeholders, who in turn influence the work that gets done. EA needs to have similar influence.
The Solution Sponsor. This is a challenging one, but very important. It’s challenging because in many organizations, IT relationships with the business are considered protected turf, and people can get really bent out of shape if you have these conversations without them there. I think we need to stop protecting these conversations and instead start encouraging them. If it can help the company deliver better solutions, then get the right people talking to each other, period. What’s really important with the sponsor is to start talking about the architecture of the effort before the funding proposal is made. If you can bring the solution architect with you, even better, because that will build rapport. Make the sponsor aware of the needs of the enterprise, work to get their support, and then when you need to make decisions within the project, the person at the top of the decision making chain should have awareness of not just the financial and schedule needs, but also the enterprise architecture needs.
The Project Manager. Finally, it’s the project manager. If you’ve properly influenced the sponsor and the solution architect, this one shouldn’t be a problem, but we shouldn’t ignore the project manager. It is their job to make sure the right things get delivered. The solution architect should be their partner in the effort, helping them to know when things are going off track from a technical perspective. There are delivery requirements, functional requirements, and architectural requirements, and the PM has to make sure all three are addressed. It is better to discuss the relative priority of each of those up front, rather than deal with the contention in the middle of the project. Will you allow the schedule to slip to maintain the right architecture? Will you sacrifice functionality for the right architecture? Talk about this before it becomes an issue. Also, if you have a formal review process, make sure the PM knows what is needed and what questions are going to be asked. They want the review to go smoothly, so you have to give them the tools they need to know when they’re ready to be reviewed and to pass without any issues.
Hopefully you’ve found this focus on solution architecture useful. As topics come up under this theme of architecture by influence, I’ll have additional posts. If there are specific questions or challenges you have, feel free to send me an email or post it via a comment.
This is a first in what I hope will be a few blogs around the subject of architecture by influence. There are no shortage of people who are writing that enterprise architects can’t be successful unless they have some teeth, i.e. the ability to stop activities in their tracks that aren’t compliant with the architectural direction. There’s also no shortage of people who have written that architecture by mandate doesn’t bode well, either. You’ll either never have that mandate (i.e. no teeth), you’ll leave so many dead bodies in your wake that morale will take a precipitous decline, or the first failure will be blamed on the mandated architecture and the team will be disbanded, or worse, fired. Well, my goal with these posts is to get away from these “what’s wrong with EA” posts and to start the conversation on ways we can make it work.
In order to do this, we first need to talk about the decision making process, which is the focus of this talk. If you don’t understand how decisions get made, you can’t hope to have systemic success with your architecture program, let alone your solution delivery efforts. How many times have you been on a project where meeting after meeting is happening and you just want to stand up and scream, “someone make a decision” It’s usually not for the lack of ideas, it’s usually because it’s unknown who has the authority to make the decision. In the early days of my career, I saw this all the time when a project had a project manager, but had no stated technical leadership. The team would look to the only hierarchy they had- the project manager- but the project manager lacked the knowledge to make good decisions. It’s the project manager’s job to make sure decisions get made, but the scope of decisions they’re normally trained to handle is schedule and resource management.
So, step one is to first understand who has the authority to make the decisions. If it’s unclear, clarify it first, don’t just bring everyone into a room and try to make decisions. There’s nothing worse than having a bunch of people in a room who think they have the power to make a decision, when they really don’t. That’s when things can get very ugly. Often times, the winner is not the person with the right idea, but rather the person who has the most domineering personality. Another common trend is that it is the person who holds the checkbook. For decisions that involve spending money, this is frequently the case. If funding is not in question, then this person may not be involved. Even worse, they may get escalated to this person (because they’re seen as the top of the food chain), at which point credibility erodes because they are likely to say, “What am I paying you people for? It’s your job to make those decisions.”
So, the next question is, how do we avoid personality-based or bias-based decisions? It’s human nature to fall into this trap, as we’re bombarded by it in virtually every facet of our life. The way I’ve found that works, and simply stated by a former boss of mine, is to get the decision criteria out on the table and get everyone to agree on it. If you’re worried about internal expertise, make it part of the decision criteria. If you’re worried that integration challenges will exist down the road, make it part of the decision criteria. Not only does this allow people to check their biases at the door, but it also gives the necessary context for people to actually present their options. If you don’t know what you’re being evaluated against, how can you hope to be successful?
This is one of my personal pet peeves when it comes to architecture reviews. Too often, the guidance for a team undergoing an architecture review is nothing more than, “you have to have one or more of these people that we believe are smart look at your architecture.” How can a team have any idea on what things are important to that reviewer or review board? They make their best guess, and then the whole thing dissolves into the reviewers trying to show that they know more than the team by finding something that was overlooked (and there’s always something) or opening up debate on other options, regardless of whether or not those options actually make any difference in what is going to be delivered. Again, it’s setting people on a path toward frustration, rather than setting them up for success. To be successful, make the team aware of what things they will be evaluated against up front, give them a framework for which options can be presented rather than an all or none checkpoint approach, and keep the focus on delivering the right thing, rather than on wielding power.
So, to summarize, here are the guiding points for analyzing your decision making process:
- Figure out who has authority to make decisions. Different people can handle different decisions, but you really want one person with the final call.
- Define the criteria for which options for each decision will be judged. Check your biases at the door. Make sure to prioritize those criteria, as well.
- Present options for the decision involved, and evaluate each option against the criteria. Avoid “I don’t know” for any criteria. If the criteria are known up front, there’s no excuse for not doing the analysis of your option against those criteria.
For some, this post may fall into the “stating the obvious” category, but at least based on my own personal experience, far more important decisions are made by personal bias or opinion than by this approach. You can make a career by having good decision-making ability, but all it takes is one bad decision to have it all come tumbling down. With a more fact-based decision making approach, it’s easier to see where the failure was due to poor, incorrect, or incomplete information supporting the decision rather than a poor decision maker.
On Twitter, Brenda Michelson of Elemental Links started a conversation with the question:
Do #entarch frameworks enable or constrain practice of (value from) enterprise architecture?
In my comments back to Brenda, it became clear to me that there’s a trap that many teams fall into, not just Enterprise Architecture, and that’s falling into an inward view, rather than an outward view.
As an example, I worked with a team once that was responsible for the creation, delivery, and evolution of data access services. Over time, teams that needed these services were expressing frustration that the services available were not meeting their needs. They could eventually get what they needed, but in a less than efficient manner. The problem was that the data services team primary goal was to minimize the number of services they created and managed. In other words, they wanted to make their job as easy as possible. In doing so, they made the job of their customers more and more difficult. This team had an inward view. It’s very easy to fall into this trap, as performance objectives frequently come from internally measured items, not from the view of the customer.
EA teams that obsess over the adoption of EA frameworks fall into the same category. Can EA frameworks be a valuable tool? Absolutely. But if your primary objective becomes proper adoption of the framework versus delivering value to your customers, you have now fallen into an internal view of your world, which is a recipe for failure.
Instead, teams should strive to maintain a service mentality. The primary focus should always be on delivering value to your customers. There’s a huge emphasis on EA becoming more relevant to the business, in order to do so, we need to deliver things that fit into the context of the business and how they currently make decisions. If we walk in preaching that they need to change their entire decision making process to conform to a framework, you’ll be shown the door. You must understand that you are providing a service to the teams you work with and helping them get their job done better that they could without you. While a framework can help, that should never be your primary focus. Internal optimizations of your process should be a secondary focus. In short, focus on what you deliver first, how you deliver it second. If you deliver useless information efficiently, it doesn’t do anyone any good.
In the Wired magazine article on the relationship between AT&T and Apple (see: Bad Connection: Inside the iPhone Network Meltdown), the author, Fred Vogelstein, presents a classic service management problem.
In the early days of the iPhone, when data usage was coming in at levels 50% higher than what AT&T projected, AT&T Senior VP Kris Renne came to Apple and asked if they could help throttle back the traffic. Apple consistently responded that they were not going to mess up the consumer experience to make the AT&T network tenable.
In this conversation, AT&T fell into the trap that many service providers do: focusing on their internal needs rather than that of the customer. Their service was failing, and the first response was to try to change the behavior of their consumers to match what their service was providing, not to change the service to what the consumer needs.
I’ve seen this happen in the enterprise. A team whose role was to deliver shared services became more focused on minimizing the number of services provided (which admittedly made their job easier) than on providing what the customers needed. As a result, frustration ensued, consumers were unhappy and were increasingly unwilling to use the services. While not the case in this situation, an even worse possibility is where that service provider is the only choice for the consumer. They become resigned to poor service, and the morale goes down.
It is very easy to fall into this trap. A move to shared services is typically driven by a desire to reduce costs, and the fewer services a team has to manage, the lower their costs can be. This cannot be done at the expense of the consumer though. First and foremost, your consumers must be happy, and consumer satisfaction must be part of the evaluation process of shared service teams. Balance that appropriately with financial goals, and you’ll be in a better position for success.
A couple of recent conversations have really caused this theme to spike in my head. In my experience, I’ve seen successful enterprise architecture and I’ve seen unsuccessful enterprise architecture. While many may put the blame on a failure to define what architecture is, I think that’s wrong. I think a recipe of failure is a lack of understanding of what the enterprise is. By that, I mean a lack of understanding of what capabilities should be managed at an enterprise level and what capabilities should not. There’s no uniform right or wrong approach, it is highly dependent on your company’s operating model as articulated in the book “Enterprise Architecture as Strategy.” In that book, the authors even state that at one extreme, a completely diversified company may have no enterprise architecture at all.
Once you understand what “enterprise” is, you have to set up the organization, processes, and governance to support that. To illustrate this point, however, let’s look at the differences today between two commonly “shared” organizations: HR and IT. Most big organizations have a centralized HR department. While I’ve never looked at the funding model for HR, my guess is that there is some overhead tacked onto every employee and every contractor that winds up paying the costs of the HR department. It’s a shared cost. One organization is normally not able to throw extra money in the pot and fund extra recruiters or benefits managers for their organization. Contrast this with IT where that’s exactly what happens. While IT may be centralized, it’s funding model is not. This results in IT organizations whose structure mirrors the business silos, and whose actions are completely controlled by the funding provided from each of those silos. What’s the point in having a central organization? That central organization really can’t dictate priorities or approaches, because someone else controls the purse strings. The right way of handling it is where the IT leader meets with the business leaders, they jointly agree on IT priorities and budget, and then the centralized IT department is funded based on those priorities with the discretion it needs to manage it from within. I’ve been at an organization that made that transition, and it was a definite improvement in the working environment, in my opinion.
Now the really interesting thing is getting that initial definition of the enterprise. The more I think about this, the more I realize that this definition is the job of Enterprise Architecture. We must architect the enterprise, meaning we come up with the proposal for what things should be enterprise and what things are best left to sub-domains. But wait, this sounds like a task, not a team. Initially, it is a task. Ongoing, however, the refinement of that definition and adjustment based on changes in the business and its climate will occur, and that is the job of the team. On top of that, there’s the enforcement aspect of making sure everyone continues to play by the rules. As an example, think about architecting the enterprise of the United States of America. The initial “architecture” creating the federated governing structure, with some capabilities provided at a federal, or enterprise, level (e.g. military forces) and others left to the discretion of the states. Since that time, the government has continued, in part, to tweak and refine what things are handled federally and what things are handled locally. The approach must always be monitored for effectiveness, responsiveness, cost, etc. Imagine, now, a different world where that structure doesn’t exist, and every cross-cutting topic is brought before a collection of state governors. Debate would occur on every single item, decisions would be extremely slow, and people with the power ($) to do so, simply would, even when it may not be in the best interest of the country as a whole. Take another scenario in recent press like immigration and border security. If the federal government says, “we must secure our borders” but doesn’t create a centralized approach for doing it, what happens? States with money may do a good job, states with others will not. One state’s approach may be completely different, making it difficult for legal immigrants to travel from state to state because the rules are so different. In other words, while all agreed that it was an enterprise goal, it was not managed as an enterprise capability. This is what happens in IT departments around the globe every single day.
My advice to my fellow EA practitioners: if you’re struggling, focus on defining the enterprise first getting buy off from senior executives on what items must be managed at an enterprise level, and then guide the transition to that approach.
All content written by and copyrighted by Todd Biske. If you are reading this on a site other than my “Outside the Box” blog, it’s probably being republished without my permission. Please consider reading it at the source.
A succession of tweets between Forrester’s Gene Leganza and Clay Richardson along with Brenda Michelson of Elemental Links caught my attention this morning. At Forrester’s Enterprise Architecture Forum next week, Clay will be reviewing a few case studies for Social BPM. It’s too bad that I won’t be there, because this sounds very interesting.
I haven’t seen any definitions yet of what socially-enabled BPM is, so I thought I’d throw together my own thoughts. First off, let’s take two dominant social technology platforms, Facebook and Twitter. I’ve previously posted that an internal Facebook for the enterprise could be revolutionary for inter-company communication. I’ve also previously posted on the role of Twitter as an information bus. So, now combine the human-facing communication of either platform’s news/event stream, the application platform of Facebook, and toss in some process modeling, orchestration, and universal task management capabilities on top of it, and I do think you have socially-enabled BPM. What could be most compelling is if there’s a way to combine the communication features of the social technology platform for “ad hoc” processes with the more formally modeled and managed processes that are the strong suite of BPM platforms to get a better view (and hopefully better management) of the processes in the enterprise as a whole.
I look forward to hearing what others think about the case studies Clay will be presenting. This is definitely an emerging area where there are opportunities to lead the back and be revolutionary.
Update: Here’s two posts from Clay on the subject that he forwarded to me. It looks like my thinking is consistent with what he had previously written on the subject. The first is titled “Social Technologies Will Drive The Next Wave Of BPM Suites” and the second is titled “BPM Promises ‘Simplicity’ In 2010. Is This ‘Hope We Can Believe In’ Or Still A Pipe Dream?”.
All content written by and copyrighted by Todd Biske. If you are reading this on a site other than my “Outside the Box” blog, it’s probably being republished without my permission. Please consider reading it at the source.
David Linthicum continued the conversation around design-time governance in cloud computing over at his InfoWorld blog. In it, he quoted my previous post, even though he chose to continue to use the design-time moniker. At least he quoted the paragraph where I state that I don’t like that term. He went on to state that I was “arguing for the notion of policy design,” which was certainly part of what I had to say, but definitely not the whole message. Finally, Dave made this statement:
The core issue that I have is with the real value of the technology, which just does not seem to be there. The fact is, you don’t need design-time service governance technology to define and define service policies.
Let’s first discuss the policy design comment. Dave is correct that I’m an advocate for policy-based service interactions. A service contract should be a collection of policies, most if not all of which will be focused on run-time interactions and can be enforced by run-time infrastructure. Taking a step backward, though, policy design is really a misnomer. I don’t think anyone really “designs” policies, they define them. Furthermore, the bulk of the definition that is required is probably just tweaking of the parameters in a template.
Now, moving to Dave’s second comment, he made it very clear that he was talking about governance technology, not the actual governance processes. Speaking from a technology perspective, I’ll agree that for policy management, which includes policy definition, all of the work is done through the management console of the run-time enforcement infrastructure. There are challenges with separation of concerns, since many tools are designed with a single administration team in mind (e.g. can your security people adjust security policies across services while your operations staff adjust resources consumption while your development team handles versioning, all without having the ability to step on each other’s toes or do things they’re not allowed to do?). Despite this, however, the tooling is very adequate for the vast majority (certainly better than 80-90% in my opinion) of enterprise use cases.
The final comment from me on this subject, however, gets back to my original post. Your SOA governance effort involves more than policy management and run-time interactions. Outside of run-time, the governance efforts has the closest ties to portfolio management efforts. How are you making your decisions on what to build and what to buy, whether provided as SaaS or in house? Certainly there is still a play for technology that support these efforts. The challenge, however, is that processes that support portfolio management activities vary widely from organization, so beyond a repository with a 80% complete schema for the service domain, there’s a lot of risk in trying to create tools to support it and be successful. How many companies actually practice systemic portfolio management versus “fire-drill” portfolio management, where a “portfolio” is produced on a once-a-year (or some other interval) basis in response to some event, and then ignored for the rest of the time, only to be rebuilt when the next drill occurs. Until these processes are more systemic, governance tools are going to continue to be add-ons to other more mature suites. SOA technologies tried to tie things to the run-time world. EA tools, on the other hand, are certainly moving beyond EA, and into the world of “ERP for IT” for lack of a better term. These tools won’t take over all corporate IT departments in the next 5 years, but I do think we’ll see increased utilization as IT continues its trend toward being a strategic advisor and manager of IT assets, and away from being the “sole provider.”
All content written by and copyrighted by Todd Biske. If you are reading this on a site other than my “Outside the Box” blog, it’s probably being republished without my permission. Please consider reading it at the source.
Sometimes a simple message can be the most powerful. In a recent discussion on a SOA Consortium phone call, I made the comment that IT needs to shift its mentality from provider to advisor. I hope that most people read this and view it as completely obvious, but recognizing the fact and actually executing against it are two different stories.
Let’s look at two trends that I think are pretty hard to argue against in most corporate IT organizations. The first trend is to build less stuff. Building less means that we’re either reusing stuff we already have, or acquiring stuff from some other source and configuring (not customizing) it to meet our needs. This could be free stuff, COTS, SaaS, etc. The point is, there is no software development required.
The second trend can be summed up as buy fewer (none) servers. Virtualization, data center consolidation/elimination, and cloud computing all have ties back to this trend, but the end result is that no one wants to build new data centers unless data centers are your business.
So, if you accept these trends as real, this means that IT isn’t providing applications and IT isn’t providing infrastructure. Then what is IT providing? I would argue that rather than looking for something new to “provide,” IT needs to change its fundamental thinking from provider to advisor or be at risk of becoming irrelevant.
Am I simply stating the obvious? Well, to some extent, I hope so. What should also be obvious, however, is that this change in role at an organizational level won’t happen by accident. While an individual may be able to do this, redefining an entire organization around the concept is a different story. A provider typically needs to only understand their side of the equation, that is, what they’re providing. If you’re a software developer, you understand software development, and you sit back and wait for someone to give you a software development task. Often times, the provider may establish some set offerings, and it’s up to the consumer to decide if those offerings meet their needs or not. An advisor, on the other hand, must understand both sides of the problem: the needs of the consumer and the offerings of the provider.
To illustrate this, take an example from the world of financial services. A broker may simply be someone you call up and say, “Buy 100 shares of APPL at no more than $200.” They are a provider of stock transaction services. A financial advisor on the other hand, should be asking about what your needs are, and matching those against the various financial offerings they have at their disposal. If they don’t understand client needs or if they don’t understand the financial offerings, you’re at risk of getting something sub-optimal.
IT needs to shift from being the technology provider to the technology advisor. Will people outside of IT continue to hand-pick technology solutions without the right breadth of knowledge? Sure, just as people today go out and buy some stock without proper thought of whether that’s really the right investment for them or just what everyone else is doing. The value add that IT needs to offer is the same that financial consultants do. We provide significantly better depth of understanding of the technology domains, along with the right amount of understanding of the business domains of our companies to advise the organization on technology decisions. For the non-IT worker that loves technology, it should be seen as validation of their efforts (not a roadblock).
The final message on all of this, however, is that I believe architecture plays a critical role. To actually build an advisory organization, you must categorize both the technology and the business into manageable domains where people can build expertise. Where does this categorization come from? Architecture. Taking a project-first approach is backwards. Projects should not define the categories and the architecture, the categories and desired architecture should define the projects.
So, you can see that this simple concept really does represent a fundamental shift in the way of thinking that needs to occur, and it’s one that’s not going to happen overnight. If you’re a CIO, it’s time to get this message out and start defining the steps you need to take to move your organization from a provider to an advisor.
Full disclosure: I’m attending Oracle OpenWorld courtesy of Oracle.
I’m having to recreate this post thanks to a bug in WordPress for the iPhone which managed to eat a couple posts, so my apologies for it being a bit shorter than hoped, since I had to recall what I was typing live.
In this session, James Kao from Oracle presented five steps to improving SOA governance. The core premise that was emphasized throughout is that the use of metadata is becoming more and more prevalent in the development world, as it is necessary to increase the efficiency of our development efforts. Examples include SCA descriptors and BPEL. We will have a big problem, however, if the operational tools can’t keep up with these advances. This same metadata needs to be leveraged in the run-time world to improve our operational processes. I’ll add to this that while much of the metadata is coming out of the SOA and BPM technology space, this concept should not be limited to just those areas. The concept of having metadata that describes solutions for gains in both the design time world and the run time world is extremely important.
The five steps presented were:
- Assess. (sorry lost the details on this one)
- Discover. This is where the metadata created at design time is leveraged to set up appropriate run-time governance.
- Monitor. The systems must be instrumented appropriately, exposing metrics, in addition to leveraging external monitors to collect information about run-time behavior.
- Control. The four examples given here were policy management, service management, server/service provisioning, and change management. Clearly, this is the actionable step of the process. Based upon the data, we take action. Sometimes that action is reflected in changes to the infrastructure via provisioning and/or change management, sometimes that action is modifications to the policies that govern the systems.
- Share. Finally, just as the metadata from design time played a role in the run time world, the metrics collected at run time can play a role in other processes. The information must be shared into systems like Oracle BAM or Oracle ER to provide a feedback loop so that appropriate decisions can be made for future solutions.
I was very impressed with James’ grasp of the space. While this session presented concepts and not a live demonstration, if Oracle Enterprise Manager can make these concepts a reality in a usable manner, this could be a very powerful platform for companies leveraging the red stack. Excellent talk.
Jeff Schneider posted the following comment to my previous post, “What are your EA Services?”
Your services feel too ‘responsive’ – like someone has to pick up the phone and call you in order for EA to be valuable. Thoughts?
I was hoping someone would ask a question along these lines, because it’s something I’ve thought a lot about. Services, by their nature, should seem very ‘responsive.’ After all, there should always be a service consumer and a service provider. The consumer asks, the provider does. In the context of an enterprise architecture team, or any other team for that matter, you do have to ask the question, “If no one is asking me to do this, why am I doing it?” Is that stance too theoretical, though?
When I think about this, I think services in this context (ITIL/ITSM) follow the same pattern that can be used for web services. There are services that are explicitly invoked at the request of a consumer, and then there are services that are executed in response to some event. In the latter case, the team providing the service is the one monitoring for the event. If some other team was monitoring for it, and then told your team to do something, then we’re back to the request/response style with one team acting as consumer and the other acting as the provider.
Coming back to the EA services, I think an Enterprise Architecture team will typically have a mix of request/response-style and event-driven services. It’s probably also true that if the EA team is closer to project activity, you’ll see more request/response services done on behalf of project teams, such as the Architectural Assessment Services and the Architectural Consulting Services I mentioned. If your EA team is more involved with portfolio management and strategic planning, then it’s possible that you may have more event-driven services, although these could still be request/response. Strategic direction could be driven by senior management, with direction handed down on areas of research. That direction represents a service request from that strategic planning group to the EA team. In an event-driven scenario, the EA team would be watching industry trends, metrics, and other things and making their own call on areas for research. It’s a subtle difference.
Anyway, I do think Jeff has a valid point, and as part of defining the services, you should classify the triggers that cause the service to be invoked. This will clearly capture whether they are event-driven or request/response. If your list is entirely request/repsonse, that’s probably something to look into. That may be what’s needed today, but you should be practicing good service management and planning for some event-driven services in the future if your team continues to provide value in the organization.
Thanks to Jeff Adkins for the good discussion about this on Twitter.