Todd Biske: Outside the Box

Warren Ritchie, CIO for Volkswagen Group of America, presented this session and told us about his personal journey with EA, its utility in a globalization concept, and how the EA program at VW Group of America provided initial benefits. He believes that EA is the missing piece in strategy management.

In his PhD dissertation (he has a PhD in Business Strategy), he looked for a more compelling explanation of why firms do or do not take advantage of a strategic opportunity: strategic choice or structural inertia? He found that small companies with a simple structure moved fast, medium size organizations (complex single business) were the slowest, and large, multi-business firms moved fast (possibly via a spinoff). The research pointed toward structural inertia being a key factor in whether or not a company took advantage of an opportunity.

So, if strategy implementation is about manipulating the structure, we cannot manage internal resources, products, and services as if they are independent things. If you can’t describe internal resource structure, you can’t implement strategy.

He went on the discuss VW’s strategy around sales and marketing globalization. I thought it was great that his diagram clearly showed areas for horizontal integration versus vertical integration. He talked about the notion of a modular platform for building cars, and how it was flexible and highly scalable. We need to do the same thing for organizations. Create a global core that can be customized for the particular regions. 70% of processes are global, 30% are local.

On speed to benefits, he suggested getting started with a specific “failure is not an option” project. Points on his slide were:

1. Layout the EA framework
2. Populate the repository as a trailing edge activity early
3. Re-Use repository content for later phases
4. First efforts are labor intensive, but returns start quickly

The project they targeted was a transition in their application management service supplier. A big step was that they took the tacit knowledge that was known in the incumbent supplier, and made that information explicit in an EA repository. They are now faster with projects because they know what things connect to each other, and by being faster, projects now cost less. The EA practice is now in high demand within the IT department and starting with the business units. The ROI they’ve achieved is well over 100% on risk mitigation alone. They are in a position where they can go to suppliers with their model, and those suppliers map to it.

The overall conclusions were:

• Organizations that are better able to describe themselves are more adaptive to market opportunity.
• Globalization strategy of sales and marketing requires a rigorous description of organization’s internal structure.
• After an initial investment in EA, each incremental investment is resulting in disproportionately positive returns.

The first session I’m in is one of the few sessions by Troux staff at the conference, being given by Bill Cason, CTO of Troux. Always nice to see a CTO doing these things.

Bill went over the IT strategy planning process, involving the business, the office of the CIO, and enterprise architecture. There was a good slide that visually showed the process as Troux sees it that I’ll try to get and repost here. Update: here’s the slide:

Early on, he emphasized the need to capture the business context in the forms of goals and strategies, as well as to have EA be the keeper of business capability maps, defined through collaboration with the business. These capability maps are what allow for fact-based conversations that aid the decision making process.

Bill’s Top 10 things to do:

1. Help your boss. Their surveys show that most CIOs are managing strategy on their own.
2. Establish sustainable processes. Get sponsorship, establish stewardship, define all roles and establish them, and get agreement on governance and measures.
3. Involve the business
4. Understand how organizations think. IT thinks about IT assets and activities, the business thinks about business capabilities. The capability map must align the IT portfolio with the business capabilities.
5. Recognize what tools they use. Business has lots of manual methods, IT has some automation.
6. Establish business context. If you can’t involve the business, at least try to understand their objectives.
7. Start with the business questions. What does the business want to do? Where should it transform? How are the transformations progressing?
8. Focus on key areas. “Burning platforms” M&A, divestitures, regulatory drivers, time to market. This helps focus the work and make it more digestible. Near time focus, grow scope over time.
9. Influence departmental behavior. Link business roadmaps to IT roadmaps, communicate the dependencies and impacts.
10. Be flexible. Executives will never use EA models.

Alex Cullen of Forrester posted an interesting blog regarding the “inevitable trend” of business empowerment. At the recent Forrester EA Forum, they invited attendees to rate on a 1-5 scale, whether or not “the EA function has close ties with business management” and whether or not the “technology strategy and standards allow for rapidly changing technologies.” Not surprisingly, in my opinion, only 33% of respondents answered positively on the first question, and only 27% answered positively on the second question.

The combination of these two questions is very interesting. I’m very pragmatic when it comes to discussions about standards. Arbitrary standards may allow someone to fill out a compliance dashboard or meet their personal or team objectives, but the majority of those standards may not have any positive impact on the company’s strategy and goals, and in fact, may be an inhibitor. At the same time, this same linkage to strategy and goals must also apply to the use of new technologies. Someone needs to be the enterprise parent that asks the question, “do you really need that?” It may be a shiny new thing, but does it make a difference in the ability to accomplish the strategy and goals?

This is by no means an easy problem. Yes, sometimes there are very clear cost-cutting initiatives that make it easy to drive certain standards decisions. Sometimes, things are not so clear. For example, I have had conversations with people in the financial services industry who told me that the technology available to the financial consultants was important for recruiting. A company with slow technology adoption processes could be at risk of losing their top consultants, or failing to attract new ones, which winds up having a direct impact on company revenues.

The end result of all of this is that work on these two items must go hand in hand. You can’t hope to establish standards in the right areas if you don’t have an intimate knowledge of the business strategy and goals. You can’t have that intimate knowledge unless you have strong ties with business management. If the enterprise architecture team does not have these strong ties, they’re going to have to balance second-hand explanations against the potentially disconnected goals of the department to which they report (e.g. IT).

The right model for EA has to be that of the trusted advisor. I’ve commented about this previously in “Enterprise Architect: Advisor versus Gatekeeper” and “IT Needs To Be More Advisory”. When EA is being grown from within IT, a big challenge may be to establish that trust. Like it or not, the EA team may be carrying the baggage of the entire IT department with you. Trust is earned, so we need to find a way to establish one or more strong relationships with key business leaders, and then use those relationships to scale from there.

On Twitter, Scott Ambler (@scottwambler) posted:

Effective IT governance is based on motivation and enablement, not command and control.

At first glance, it would be hard to argue with this statement. In general, most people don’t like command and control, and who wouldn’t prefer the carrot over the stick? Having thought a lot about governance (and written a lot, too hint, hint) I had to go deeper on what effective governance really entails. I’ve seen situations where a command and control governing style has succeeded and ones where it has failed. I’ve seen the same thing for motivation and enablement styles, as well. So what really is the key?

In situations where things turned out good for the company, it was because the organization, as a whole, all saw things in the same way. They understood the strategic priorities and goals and balanced these against departmental or project priorities goals in an appropriate way. Where things turned out bad is where those priorities and goals were not well understood, if they even existed at all. In other words, everyone had their own opinion on what the right thing to do was. In general, people always had good intentions with the decisions that they made, but the criteria they decided to use to choose the best approach was not consistent from person to person or team to team. In the absence of this understanding, neither command and control or motivation and enablement will fix things. Put in a bunch of commanders that don’t have a shared understanding, and you get a power struggle. Likewise, if we simply try to remove barriers and “enable” people, that is not going to help when accomplishing goals involves cross-project or cross-organizational efforts.

To have effective governance, you must first have clarity and a shared understanding of the goals and strategy around your efforts. If you don’t have this, then you may need to begin with a heavier command and control approach to not only get the word out, but to ensure that it sinks in. Once you build that shared understanding, a shift to a focus on enablement is certainly in order. If the understanding has taken root, people don’t need to be controlled anymore, and that should be your goal. Along with this, however, your people must be able to recognize when things fall into the grey area. As part of being enabled, there needs to be a trust factor that people will make those grey areas known to the command structure, even perhaps with options that look at things from both a micro and macro level. The command structure, in turn, must make decisions in an efficient manner, and then work its communication processes to augment the shared understanding in the organization.

If I had to put effective IT governance in a nutshell, it’s all about communication. If you communication is great, which means that you effectively communicate not just the direction but the reasons behind it, and you have a feedback process for discussing it with people who may disagree with it, you’re likely to have effective governance.

Rob Koplowitz of Forrester recently posted, Why Tibbr Matters. He provided some examples of where an activity stream across a network like Tibbr could add value, and some examples where it couldn’t. I responded with a comment and I wanted to elaborate on my comments here.

Activity streams tied to your company that are available through tools like Chatter, Yammer, and Tibbr have potential for adding value, but there’s some big barriers that must be overcome. In my experience, I’ve used email, Sharepoint and other other internal portals, and Yammer inside of a corporate setting, and there’s two simple objectives that these tools should have, at a minimum:

1. Moving information from the privileged few to a broader audience.
2. Making new information available that previously wasn’t.

On the first item, a challenge that probably every organization has is getting the information to the right people. The information exists, but it only spreads through word of mouth or to people that the information holders think need to be aware of it. The twitter model is the right approach for addressing this, by allowing people to follow people or topics of interest (either via saved keyword searches or hashtags), rather than having to wait until it is explicitly sent to them. In order for this model to work, however, all information must be public. As soon as private, directed messages come into play, that information is now hidden. I don’t see this as the bigger of the two challenges, however, as at least the information exists, it’s just not getting everywhere it needs to go.

The second item is the greater challenge. If there is information that simply isn’t being communicated, there is no tool that is going to magically make that information appear. The more information sources you have participating in the network, the greater potential you have for getting value out of that network. Why does everyone join Facebook? It’s the network with the greatest participation, and therefore, the greatest potential value. There’s a catch-22 here, because you want participants to get value quickly, so they stay in the network, but once you get over the hurdle, the growth will come. So how do we do this?

In a corporate setting, the participants are not just your employees. The participants must include your systems. This is why Tibbr is potentially in a good spot. Tibco’s background is not in collaboration or social media, it is in system integration. Unfortunately, all of the web-based request/response systems over the past decade have gotten us away from the asynchronous, event-based system design of the past. Even SOA tends to imply a request-response paradigm in most people minds, meaning I have to know what to ask for in advance. Both our systems and our people need to expose items of interest without any preconceived notion of who might be interested. Yes, we need to be cautious about signal to noise ratio, but I don’t think that problem is any different than trying to manage redundancy in an application or service portfolio. As part of your deployment process, get a list of the events/messages that are available, categorize them, and manage them effectively. If the Twitterverse can quickly come up with accepted hashtags, why can’t we do the same inside our corporate worlds?

Since I’ve previously asked for this year to be the year of the event, let’s do so in a way that allows these events to feed into our internal activity streams and social networking tools, and start getting real value out of these technologies.

In this, my first blog post of 2011, I’d like to issue a challenge to the blogosphere to make 2011 the year of the event. There was no shortage of discussions about services in the 2000’s, let’s have the same type of focus and advances in event’s in the 2010’s.

How many of your systems are designed to issue event notifications to other systems when information is updated? In my own personal experience, this is not a common pattern. Instead, what I more frequently see is systems that always query a data source (even though it may be an expensive operation) because a change may have occurred, even though 99% of the time, the data hasn’t. Rather than optimizing the system to perform as well as possible for the majority of the requests by caching the information to optimize retrieval, the systems are designed to avoid showing stale data, which can have a significant performance impact when going back to the source(s) is an expensive operation.

With so much focus on web-based systems, many have settled into a request/response type of thinking, and haven’t embraced the nearly real-time world. I call it nearly real-time, because truly real-time is really an edge case. Yes, there are situations where real-time is really needed, but for most things, nearly real-time is good enough. In the request/response world, our thinking tends to be omni-directional. I need data from you, so I ask you for it, and you send me a response. If I don’t initiate the conversation, I hear nothing from you.

This thinking needs to broaden to where a dependency means that information exchanges are initiated in both directions. When the data is updated, an event is published, and dependent systems can choose to perform actions. In this model, a dependent system could keep an optimized copy of the information it needs, and create update processes based upon the receipt of the event. This could save lots of unnecessary communication and improve the performance of the systems.

This isn’t anything new. Scalable business systems in the pre-web days leveraged asynchronous communication extensively. User interface frameworks leveraged event-based communication extensively. It should be commonplace by now to look at a solution and inquire about the services it exposes and uses, but is it commonplace to ask about the events it creates or needs?

Unfortunately, there is still a big hurdle. There is no standard channel for publishing and receiving events. We have enterprise messaging systems, but access to those systems isn’t normally a part of the standard framework for an application. We need something incredibly simple, using tools that are readily available in big enterprise platforms as well as emerging development languages. Why can’t a system simply “follow” another system and tap into the event stream looking for appropriately tagged messages? Yes, there are delivery concerns in many situations, but don’t let a need for guaranteed delivery so overburden the ability to get on the bus that designers just forsake an event-based model completely. I’d much rather see a solution embrace events and do something different like using a Twitter-like system (or even Twitter itself, complete with its availability challenges) for event broadcast and reception, than to continue down the path of unnecessary queries back to a master and nightly jobs that push data around. Let’s make 2011 the year that kick-started the event based movement in our solutions.

According to ZDNet’s Joe McKendrick’s coverage of the recent Gartner Application Architecture, Development, and Integration summit, SOA governance and siloed thinking is top of mind.

If this really is the case, how do we make our governance efforts more effective? The more I think about this, the more I come back to a recent post of mine from earlier this year: “Want Successful Enterprise Architecture? Define ‘Enterprise’ First.” I’m convinced that this is a critical step for any effort that tries to go beyond a project-level scope, SOA initiatives included. If you don’t provide a structure that says what things will be implemented and managed at an enterprise level, versus a domain level or project/team level, anything with the term “enterprise” will be a struggle.

Too often, the approach to governance is concerned with establishing oversight, not establishing outcomes that are rooted in an agreed upon definition of what will be managed at an enterprise level, a domain level, and at the project level. Does it really help to set a standard that a particular coding library must be used when there is no central team that manages the library, no centralized support team, and no stated strategy for developer portability across projects? No, it just gets people up in arms and accusations of EA or the governance team being an ivory tower that sets arbitrary standards.

In my book, I defined governance as the combination of people, policies, and processes that are put in place to ensure the organization achieves one or more desired behaviors and outcomes. It’s not there to simply have a check mark to that says, “I went through a review.” In the absence of clear desired behaviors and outcomes, that’s what you will have. There is no reason to have an enterprise architecture team review a project if there are no things that are managed (or desired to be managed) at an enterprise level. You need to have some idea of what those things are up front, along with a mechanism for quickly making decisions on new candidates for enterprise items. The project team must know that this analysis will be done, and that it is a necessary part of achieving the company’s strategic goals, which they should be well aware of. Lack of communication of these goals can be just as detrimental and is often a symptom of lack of agreement on enterprise goals or inadequately specified goals: “Sure, we need to cut our IT costs by sharing more systems. I’m all for it as long as they’re not mine.” Someone needs to define exactly what the target areas are.

To be successful, we must define the desired outcome first. We must clearly establish the list of things that must be managed at an enterprise level, a divisional level, or left to the discretion of individual projects/teams. In fact, it’s even more fundamental than this. We can’t even know what success is without doing this step. There were no shortage of companies in the past that stated they were adopting SOA, my question to them would be, “How do you know when you’ve been successful?” Simply having a bunch of services doesn’t mean you’ve adopted SOA, it has to be the right services. Too often, enterprise architecture teams are positioned for failure because this fundamental step has not happened. Before you task your enterprise architecture team with reviewing all projects, make sure you’ve defined what enterprise is. If you haven’t, task your enterprise architecture team with doing the analysis of what’s out there and coming up with some recommendations. Then, your governance program will actually have a desired outcome to use in their reviews.

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.

Twitter was a buzz with Google TV yesterday, and of course, people were making comparisons to Apple TV, talking about apps the whole time. I watched the video on YouTube, and frankly, I didn’t see anything revolutionary. I saw a bunch of features that may cater to the tech crowd, but will largely go unused for the masses. This doesn’t mean that Apple TV is any better, but frankly, I do think Apple is doing the right thing in not loading down their device with a bunch of fluff that people won’t use.

There’s one thing I do with my TV, and that’s watch video. I don’t need to surf the web. I don’t need a 1080p Twitter interface. I don’t need to play FarmVille (I don’t do that on other devices, either). Perhaps they’re coming, but in the promo video, I saw very little video. The NBA Game Time thing I saw filled the screen with stats but had no video! Isn’t watching the game more important? The only thing that came close was the CNBC app, which allowed access to video on demand, versus the CNBC schedule on your cable or satellite. What I want, and it’s something that can’t be done because of the content providers, is to have digital access to all of my video, on my TV and my mobile devices. This includes the subscription package from my satellite provider, the HD video I shoot with my camcorder, and the DVDs and Blu-Ray discs I buy at the store. I need an iTunes library for video.

Here are the problems today. I can’t take a show that I’ve recorded on my DVR and watch it while on the treadmill at the gym or on the plane while traveling. Yes, there’s slingbox, but I don’t want to be dealing with the poor Wi-Fi connections in a hotel room, and it certainly doesn’t work if Wi-Fi isn’t available. DVDs and Blu-Ray aren’t as problematic as there are means for ripping DVDs, and many Blu-Ray discs come in packages with a digital edition. For road trips, I know I will be soon at the point where each kid has a device in front of them where they can pick their own movie to watch without any cables, piles of DVDs, and arguments because two kids want one movie and the other one doesn’t.

Apps are simply a gimmick to try to get any of these devices to make some headway. The only apps that will work for TV are games, because we’re already doing that with the Wii, the XBox, and the PlayStation. If Google or Apple wants to go after the gaming market, then an app store for a TV set top box may make sense. Otherwise, until the content providers make their video available in Internet-based channels, I just don’t see it happening. I’ll get my $99 dollar Apple TV, simply because it’s now the right price for doing the one thing that I need it to do, which is give me access to my home video library on a big screen. Apple’s shown that you can make money by doing a few things extremely well, rather than trying to sell based on the number of bullets in your feature list.

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.

Pardon the Phineas and Ferb reference, but when I read this post from Chris Lockhart, I couldn’t help but think of Professor Doofenschmirtz and his inventions. I really liked this post from Chris and how it emphasizes understanding the nature of the problem at hand. I’ve had first hand experience at more than one company where people had solutions without a clear idea of what problem it was going to solve (ESB anyone?).

A description that I’ve used before is to talk about the left and the right hand side of the equation. It is the architect’s job to understand both sides and find the match between them. The technology available to you is the right hand side. The capabilities that need to be provided (or the problems that need to be solved) are the left hand side. There are plenty of things that can go wrong. For example, if you only have one thing on the left hand side, “I need an application that does this,” it’s too coarse grained to map to any single thing on the other side, and now it puts you at risk of just choosing arbitrary technologies based on experience or preference rather than the capabilities needed. If you have multiple technologies that all map to the same set of capabilities, then you either have more technology than you need, or you haven’t defined your capabilities to the right level of granularity.

This theme gets back to the archivist versus activist discussion. If you only look at the technology side of the things, you become an archivist. You can’t be an activist unless you can adequately describe the problems and the capabilities that will be addressed by changes to the technology.

Great post Chris. To end on a Phineas and Ferb quote, “Mom, those enterprise architects are blogging again!”

While I’m not doing much these days in the BPM space, I did recently have lunch with a friend of mine who works for Genesys Lab. I don’t normally talk about vendor products by name, but the iWD (intelligent Workload Distribution) product had a different enough approach from things I’ve seen that I thought I’d share it. In the spirit of full disclosure, I’m doing this on my own time (and dime), simply because I thought the solution was interesting. Hopefully you will too.

In the past, the BPMSs that I dealt with (and the businesses trying to use them) were primarily focused on process automation and process management. Process automation tries to automate as many of the tasks within the process as possible. More importantly, the tools tried to put a process centric view around collections of tasks so that they could be more effectively managed. When successfully applied, these tools have delivered an increase in productivity, but there’s still plenty of room for more improvement. This is where iWD comes in.

iWD, as the name implies, focuses on the distribution of the manual tasks associated with business processes. It is not a BPM tool on its own, rather, it is solely focused on the distribution of tasks from your systems to the individuals that will execute them. Based on what I saw, you can think of iWD as a context-aware distribution engine. In some tools, a “worker” logs into the queue associated with a particular process and takes the next item off the queue. What if they’re not the most qualified for that task? What if there are other tasks associated with another process that are more important? What if customers have varying SLAs that cause one customer’s tasks to take precedence over another’s. By taking into account the customer and any associated SLAs, the skills and location of the workforce, and other factors, tasks can be distributed from across all processes to the global workforce in a more efficient manner.

Anyway, with context become increasing important in today’s systems, most commonly associated with location-based services, I thought this was a great example of using a variety of contextual items to improve the distribution of tasks in a BPM system. You can learn more by visiting the Genesys Lab website here. I’d love to hear other examples of context-aware computing, feel free to comment or send me a message.