Todd Biske: Outside the Box

Archive for the ‘Business’ Category

A couple of weeks ago, I asked a simple question on Twitter: Should Enterprise Architects have/get an MBA? That meme made its way to InfoQ, so I figured I should actually post my own thoughts on the subject.

First, a full disclaimer: I don’t have an MBA. I do have a MS in Computer Science from the University of Illinois (go Illini!). At the time I got my Master’s, a friend of mine took a different route and did a combined MCS (Master of Computer Science)/MBA degree. In retrospect, I wish I had taken that route. Part of my reasoning to not go that route was the whole MCS designation. Who has ever heard of that? Even from an institution like Illinois, would anyone have known what it is? For those of you wondering, it’s basically a course-only option for a Master’s degree. Getting an MS required writing a thesis. Getting an MCS did not. More importantly, however, I realize now that my interests lie more in the application of technology than in the technology itself. I had inklings of it back then, but at that time, it was far more important to be strong in technology first, rather than the domains in which it was applied.

Today, it’s a different story. There are no shortage of tech-savvy people in the business, so simply being a technology expert is not going to get you as far as it did 20 years ago. I’ve seen enough headlines that say IT departments are shrinking, meaning that some of the technology knowledge needed is being provided by people outside of IT. I don’t think this trend is going to reverse itself, so those of us that want to make a career in the application of technology will increasingly need more business-savvy.

So, should we all go back to school and get MBA’s? I view it as a tool in your toolbox. It is not a guarantee of success, but it is something that can make the path easier. Having long term career goals and a clear idea on what it will take to achieve them is probably far more important. Some companies may look highly on MBAs in making personnel decisions, others may not. Those are all factors to consider.

The other thing I wanted to comment on is the fact that many (IT) people lamented that EA isn’t part of the MBA program. I don’t agree with this at all. It’s a business degree, and like it or not, EA is still viewed as a technology discipline, not a business discipline. I do believe, however, that MBA programs should include some aspect of technology management. If an MBA prepares you to be a CEO, shouldn’t you have some idea on what your CIO and CTO should be doing?

As for me, getting an MBA is on my radar, but I haven’t yet made a decision on it. I definitely am reading more business strategy books, and for now, I think that’s the right approach for me, as frankly, I’m more concerned about paying for my kids’ education than financing continuing my own. But if I were in college today, given what I have learned about my interests in applying technology rather than building technology, I would definitely take that path, combined with a technology degree.

Jeff Scott recently posted a blog listing 14 challenges faced by business architects. They really apply to any enterprise architecture practice, and I wanted to call out and comment on a few of them.

Lack of business skills in the EA team. I commented directly on Jeff’s post on this one. I am sure there are many EA’s that have heard this statement, the problem is that it isn’t actionable. What specific skills or knowledge is missing? If you can’t get a straight answer on this, be wary of the protectionist culture that exists in many organizations. This is even expressed in another one of Jeff’s challenges, “Gatekeepers protect their business relationships.” We should all be focused on achieving the business goals, but frequently our actions are more geared toward protecting turf and climbing the corporate ladder. Someone who refuses to tell you how you can improve may be guilty of this practice, whether done with intent or simply because that’s the culture. This is why you must follow the words of another Forrester analyst, Gene Leganza, and answer the question, “What’s in it for me?” (Forrester subscription required).

An approach I like to use is to always emphasize that I’m here to help. I’m not here to be the police force and a bottleneck, I’m here to make our outcomes better. If they have people performing functions similar to enterprise architecture, but perhaps called something different, don’t turn it into a turf battle because you will lose, assuming the group is having success with it. They’re already performing the function, so unless you have a way to make that function better, there is no impetus for them to change. One thing I’ve done in those situations is to turn the conversation around and get them to start sharing their practices with other teams, and offer to be the facilitator of that communication. That can certainly play to the ego of any protectionist, but it can also be a great asset for you in demonstrating the value of the practice of architecture. Remember, it’s more important to establish the practice than it is to establish the team. Otherwise, you’re just falling into the same turf war culture that everyone else does.

Another challenge Jeff mentioned is a culture of change resistance. The scenario I described above was one where no change was needed, because the practice was being done with good results. If the results are not good, change is needed. Prior to any discussion on how to solve the problem, you have to get agreement that there is a need to change. If you get that agreement, now you can have a solid discussion. If someone doesn’t agree on the approach, ask to come up with an alternative, because you’ve already reached agreement that something needs to change.

Of the rest of the challenges, there are two others that I wanted to call out, you can review the rest on Jeff’s blog. They are: “Business units plan and work in silos” and “Tactical business focus.” These two strike at the heart of my previous post on defining the enterprise first. If the business hasn’t recognized that there are certain things that must be addressed at an enterprise level, then clearly anything with an enterprise scope will be a challenge. These are cultural issues that may be outside of EA’s ability to address, yet they are huge impediments to a successful practice. My experiences indicate that it will take someone at an executive leadership level to make this happen. They must be interacting with the directors of those silos and the common leadership above. You may be able to get some things done at a grass roots level because some individual managers may be open to shared planning, but it’s hard to turn that into systemic change without help from the top.

Thanks to Jeff for collecting these challenges, I hope others will contribute to actionable guidance that can help overcome them.

Back in March of this year, I asked “Is Twitter the cloud bus?” While we haven’t quite gone there yet, Tibco has run with the idea of Twitter as an enterprise messaging bus and announced Tibbr. This is a positive step toward the enterprise figuring out how to leverage social computing technologies in the enterprise. While I think Tibco is on the right track with this, my pragmatist nature also sees that there’s a long way to go before these technologies achieve mainstream adoption.

The biggest challenge is creating the robust information pool. Today, the biggest complaint of newcomers to Twitter is finding information of value. It’s like walking into the largest social gathering you’ve ever seen and not knowing anyone. You can walk around and see if you overhear someone discussing something interesting, but that can be a daunting task. Luckily, however, there are millions of topics being discussed at any given time, so with the help of a search engine or some trusted parties, you can easily begin to build the network. In the enterprise, it’s not quite so easy.

When looking at information sharing, here are two key questions to consider:

• Are new people receiving information that they would not otherwise have seen, and are they contributing back to the conversation?
• Are the conversation groups the same, but the information content improved in either its relevance, timeliness, quality, preservation, or robustness?

If the answer to both of those is “no”, then all you’ve done is create a new channel for an existing audience containing information that was already being shared between them. Your goals must be to enable one or more of the following:

• Getting existing information to/from new parties
• Getting new information to/from existing parties
• Delivering more robust/higher quality information to/from existing parties
• Delivering information in a more timely/appropriate manner to existing parties
• Making information more accessible (e.g. search friendly)

The challenge in achieving these goals via social networking tools begins with information sources. If you are an organization with 10,000 employees, only a small percentage of those employees will be early adopters. Strictly for illustrative purposes, let’s use IT department size as a reasonable guess to the number of early adopters. In reality, a lot of people IT will jump on it, as will a smaller percentage of employees outside of IT. A large IT department for a 10,000 person company would be 5%, so we’re looking at 500 people participating on the social network. Can you see the challenge? Are these 500 people merely going to extend the conversations they’re having with the same old people, or is the content going to meet the above goals?

Now comes along Tibbr, but does the inclusion of applications as sources of information improve anything? If anything, the way we’ve approached application architecture is even worse than dealing with people! Applications typically only share information when explicitly required by some other application. How many applications in your enterprise routinely post general events, without concern for who may be listening for them? Putting Tibbr or any other message bus in place is only going to be as valuable as the information that’s placed on the bus and most applications have been designed to keep information within its boundaries unless required.

So, to be successful, there’s really one key thing that has to happen:

Both people and applications must move from a “share when asked” mentality to a “share by default” mentality.

When I began this blog, I wasn’t directing the conversation at anyone in particular. Rather, I made the information available to anyone who may find it valuable. That’s the mentality we need in our organizations and the architecture we need in our applications. Events and messages can direct people to the appropriate gateway, with either direct access to the information, or instructions on how to obtain it if security is a concern. Today, all of that information is obscured at a minimum, and more likely locked down. Change your thinking and your architecture, and the stage is set for getting value from tools like Tibbr.

A Gartner press release resulted in some very good posts in the blogosphere related to the future of enterprise architecture. Gartner coined the term ’emergent architecture’ and encouraged companies to adopt it. For the record, I’ve decided that I really don’t like that term, and I don’t think Gartner did a very good job of defining it. They provided a list of seven differentiators from “the traditional approach to EA” but, as Mike Rollings of Burton Group pointed out in his post, most of these things are items that many practicing enterprise architects already did and knew. Do we really need a term for what many of us are already doing?

The post that I really liked came from Dion Hinchliffe at ZDNet. The reason for this is the image that he used in the post, shown here:

While I still don’t like the use of the term emergent architecture and “non-deterministic outcomes”, the picture tries to draw a picture of the forces the come into play in producing solutions.

So what is the role of EA in the future? First, the thing that doesn’t change is the role of EA in providing context. This context is an influencer on the activities that occur in the enterprise. Dion’s drawing attempts to touch on this, but goes at the scope of influence in terms of who can be influenced, rather than the information used to influence. It’s the role of the enterprise architect to bring additional context from outside of the normal scope of the effort to the solution discussion. Influence is not about centralized decision making, so as Mike Rollings called out, most EA’s have never been a centralized decision maker for all things architecture and never will be. We’re simply another party providing influence. Sometimes we have stronger methods, sometimes someone else does. In my book, SOA Governance, I emphasized policy creation first, then policy communication. If the policies are known, any decision maker can apply those policies consistently.

What Dion’s diagram doesn’t capture, is the changing way in which solutions get done. He still has the “projects” box up there. There are many of us that feel this project-based culture is part of the problem. If we take a more product-based or even service-based view of our solutions, those solutions will need to be nurtured and evolve over time, rather than stood up, ignored, and then uprooted with significant effort. This notion, as others have called out, including Neil Macehiter and Neil Ward-Dutton in their book The Technology Garden and practicing enterprise architect James McGovern in his blog, is that of gardening. Do you simply let anything emerge in your garden? No. You plant specific things, remove the weeds, remove weak plants, change some things from year to year, etc. If you don’t plan the garden properly, weeds can choke the life out of other plants, or there can be conflicts within the garden itself, with one type of plant consuming higher amounts of resources, causing others to wither and die.

Coming back to the role of EA as influencer though, the thing we must realize is that the dynamics around us are changing, and as a result, it may change who and how we influence. More and more things are bought rather than built. The level of consumer technology has changed the bar in terms of what individuals can do and expect. If we don’t change our ways along with it, our ability to influence will be diminished. This doesn’t mean things are now emergent. There have always been things that have been emergent, and a healthy company always has some efforts that fall into the category of throw it against the wall and see if it sticks. What’s changed is the pace at which we can do it. We need to incorporate this into the way we execute. I believe the trend toward business architecture is a clear sign of EA trying to do this. We must remember, however, that the artifacts and techniques used to provide context to developers and engineers may not work with the business. We need to speak the business language, not try to get them to understand ours.

I’ve refrained from incorporating the current economic crisis into my posts… until now. In a recent discussion, I compared the current situation to what many, many people do every new year. They make a resolution to lose weight, go on some fad diet or start going to the fitness center, maybe lose that weight, but then go right back to how their behavior was a few months prior and gain that weight (and potentially more) right back.

Enterprises are in a similar state. Priorities have shifted to where cost containment and cutting are at the top of the list. While the knee-jerk reaction is to stop investing in any long-term initiatives, this could be a risky approach. If I don’t eat for 4 days, I may quickly drop the weight I need to, but guess what? I still need to eat. Not eating for 4 days will only make me more unhealthy, and then when I do eat, the weight will come right back.

These times should not mean that organization drop their efforts to adopt SOA, ITIL/ITSM, or any other long-term initiative. Most of these efforts try to achieve ROI through cost reduction by eliminating redundancy in the enterprise, which is exactly what is needed today! The risk, however, is that these efforts must be held accountable for the goals they claim to achieve. They must also be prepared to adjust their actions to speed up the pace, if it is possible. No one could have predicted the staggering losses we’re seeing, and sometimes it is necessary for a company’s survival to adjust the pace. If these efforts are succeeding in reducing costs, however, we shouldn’t kill them just because they take a longer time to achieve their goals, otherwise we’ll find ourselves back in the same boat when the next change in priorities or goals happen.

The whole point of Enterprise Architecture, SOA, and many of these other strategic IT initiatives is to allow IT to be more agile- to respond more quickly to changes in the business objectives. Guess what? We’re in the middle of a big unprecedented change in our lifetime. My guess is that the best survivors of this meltdown will be organizations that don’t go on a starvation diet, but instead simply recognize that their priorities and goals have changed and execute without significant disruption to the way they utilize IT. If your EA team, SOA efforts, ITIL efforts, or anything else are inefficient and not providing the intended value, then you’re at risk of being cut, but you were probably at risk anyway, now someone just happens to be looking for targets. If EA has been adding value all along, then you’ll probably be a strategic asset that will help your organization weather the storm.

Presenter: Al Newman, Director of Architecture Services at Allstate Insurance Company

Al discussed Allstate’s journey on the path to establishing a business architecture practice at Allstate.

He walked us through an eight step process:

1. Define business architecture
2. Secure executive sponsorship
3. Develop a framework
4. Secure an initial engagement
5. Build an engagement team
6. Creating a competency center
7. Build out infrastructure
8. Formalize the operating model

Two highlights that I wanted to call out. First, he’s emphasized the need for an engagement model. I’ve seen too many teams, whether formally on the org chart or not, that don’t have an idea on how either the team members or the artifacts that they may create will be utilized within project efforts. In the IT organizations I’ve seen, the work gets done in projects, period. Architecture teams that don’t have people formally allocated to projects need to figure out how their artifacts and/or staff will be utilized in those projects.

Second, he emphasized the need for business architecture in making solid project decisions. I couldn’t agree more, and have a chapter discussing this in an SOA context in my book. In the context of SOA, one question that gets asked is “How do I build the right services?” Asking this question after a project has been initiated is already problematic as the project establishes scope boundaries, and changing those requires more effort than it would have if those discussions were had during the project definition process.

Do you have clarity of purpose in your job, your projects, your teams, your committees? I’m seeing more and more that lack of clarity in purpose is a very common problem, and one that frequently goes unnoticed until things are in a very bad state.

Why don’t we pick up on this? Human nature certainly has a part in this. We go through life being told what to do without being told why. Some things need to be done on trust- trust that the person giving the direction understands the purpose. If they don’t, then the problem can begin. Another problem is that I don’t believe we’re a community of Wallys. We like to be doing something, we like to be productive, and we like to have a purpose. Therefore, if we haven’t been given one, we’ll probably make one up. Unfortunately, in a team setting, my perception of purpose may differ from my teammates, which has the potential to create tension (there’s good tension and bad tension, but that’s a subject for another day). My teammate and I may have the same perception of purpose, but that may be different from someone outside of the team. That’s an even more dangerous situation, because now the team thinks they are doing good work, but the perception of an outsider is exactly the opposite.

Take my job: enterprise architecture. Most EA’s I know, myself included, would consider themselves big picture thinkers. Our purpose, however, is not just to establish strategic direction, but to ensure that strategic direction is followed. If all we do is create Visio and Powerpoint, and don’t also include planning, communication, and mentoring, are we success? All of the outsiders may talk to an enterprise architect and walk away thinking that person is brilliant and has a great vision, but if their purpose is also to get the organization there, and the organization isn’t moving any closer, that’s a problem.

Finally, I think it’s very easily to lose sight of our purpose as we get bogged down in the day to day efforts. It’s important to go back and review your purpose on a regular basis and make sure you’re staying on track and completing all aspects of it, and if not, seek help. Get a mentor or coach, recognize your strengths and weaknesses, and take the necessary steps to do it. If the current path isn’t working, something needs to change. If you don’t change, neither will the outcome.

FYI: I’ve signed up for Twitter. I’m somewhat skeptical about it, but I figured the only way of understanding whether its worth my time or not is to try it. My id is toddbiske, follow me here.

Presenters: Anne Lapkin and Colleen Young

One thing all of the presenters in the EA Summit are very good at doing is using consistent diagrams across all of their presentations. This is at least the third presentation where I’ve seen this flow diagram showing linkage between business goals and strategy, and business planning and execution. Unfortunately, Anne points out that the linkage is where things typically break down.

Colleen is now discussing strategic integration, which begins with an actionable articulation of business strategy, goals and objectives. From there, she recommends a standardized, integrated, results-based management methodology. As a result, she claims that we will see exponentially greater benefits from enterprise capabilities and investments.

Anne is speaking again and emphasizing that we need a unified contextual view. This consists of a goal, which is one level deeper than the “grow revenues by XY%” which includes a future end state with a timeline and measurable targets, principles that establish the desired behavior and core values, and relationships.

Colleen now has a great slide up called, “The Implication of ‘Implications’.” The tag line says it all- “Unclear implications lead to inconsistent assumptions and independent response strategies that inevitably clash.” Implications that must be investigated include financial implications, business process implications, architecture implications, cultural change implications, and more. All parties involved must understand and agree on these implications.

A statement Colleen just made that resonates with my current thinking is, “Based upon these implications, what do I need to change?” All too often, we don’t stop to think about what the “change” really is. Work starts happening, but no one really has a clear idea of why we’re doing it, only an innate trust that the work is necessary and valuable. If the earlier planning activities have made these goals explicit, the execution should be smoother, and when bumps in the road are encountered, the principles are right there to guide the decision making process, rather than on relying on someone’s interpretation of an undocumented implication.

Once again, this was a good session. I know I’ve commented on a few sessions that they could have been a bit more pragmatic or actionable, this one definitely achieved that goal. I think the attendees will be able to leave with some concrete guidance that they can turn around and use in their organizations.

Presenter: Richard Buchanan

The first topic Richard is covering is the need for enterprise architects to master strategic thinking. His current slide is consistent with an earlier talk today, showing that enterprise strategy is at the intersection of three disciplines: Enterprise Strategy and Planning, Enterprise Architecture, and Enterprise Portfolio Management. He states that enterprise architecture must translate business vision and strategy into effective enterprise change. He’s discussing how a budget and the organization chart are not part of the business strategy, pointing out that a budget should be a downstream deliverable derived from the business strategy. Great point. His definition of strategy includes an organization’s environment, goals, objectives, major programs of action, and the resource allocation choices to execute them.

The next topic he is covering are the categories of tools and techniques that are used in developing a business strategy. These are not software tools, as the first one he’s showing is Porter’s 5 Forces Model (this is second time Michael Porter has been referenced at the Summit). He’s challenging us to go and find the people in our organization that are looking at these things. Good advice. There’s no doubt that if you want to do strategic planning, you need to be looking at these five forces, and there’s a good chance that someone at the company (probably outside of IT) is already doing this. The same thing holds true for the other categories of tools that he has went through.

The final point he’s covering is how to leverage these strategic tools within the EA process. To some extent this is motherhood and apple pie, but it’s very good advice, especially knowing that many EA’s have grown out of the world of application development and may still be very technology focused. As a result, it’s entirely possible that the EA team has never read the company’s annual report. It’s even more likely that EA hasn’t seen things like competitive analysis documents. If an EA doesn’t understand how a company competes, how can they make appropriate decisions? Speaking very broadly and citing Michael Raynor’s earlier presentation, do you know whether your company differentiates on cost or on products? Both of those can have significant impacts on how information technology is leveraged. A company that differentiates based on product excellence and customer service must have significantly better technology for understanding their customers than a company that simply tries to be the lowest cost provider in the marketplace.

My final thoughts: There’s not much to disagree with in this presentation. I think he paints a great picture of what many of us would like to be doing. The challenge I suspect that many attendees have is that our EA organizations, as a previous presenter put it, “are mired in the world of technology architecture.” Somehow, we need to find a seat at the strategic planning table so when we ask about some of these artifacts, everyone knows its importance versus stopping us in our tracks and asking, “Why do you need it?”

Presenter: Betsy Burton

The presentation is starting out with a future vision statement. They believe that “by 2011, the majority of automated business processes at Global 1000 organizations will have evolved our thinking about processes with a shift from linear to nonlinear. Processes will have evolved to include a combination of formal workflow, information analysis, social networks, collaboration and ‘person-centric’ processes.”

She states that the goal of business architecture is to create the foundational artifacts for people to define the organization and enable change in the organization toward a future state. The interesting term in this statement for me is “organization.” Having roots in IT, we often want to talk about technology, and the application of technology, but when we bleed into organizational discussions, many architects think that it’s the job of management. Guess what? Organization can be an impediment or an enabler for being successful with technology so it is something that we need to think about. If it’s management’s responsibility, then invite them to the table and include them in the discussions so your efforts can be successful. As she just stated, “70% of what EA does is family counseling.” Don’t ignore the people!

She’s now moved on to the dimensions of business architecture. She includes people, financials, organization, and process. All of these are layered across the business functions of the organization. If we have these dimensions, we then need to develop requirements of business processes, the principles that guide people’s use of business processes, and the models of what the processes should look like in the current and end state. She now has a slide, and she’s showing an example of an anchor model and it’s importance to Enterprise Architecture. I’m really glad she called this out, because it aligns directly with my horizontal/vertical thinking I’ve mentioned before. I called this out back in the December EA Summit, and it’s nice to see that their thinking has continued to evolve. The anchor model is a representation of the business capabilities of the organization, and as the name suggests, it’s an anchor for other efforts like SOA and BPM.

There’s a ton of good information being presented here at a very fast pace, so I’m not going to keep trying to quote things. They’ve given a great walkthrough from the anchor model into some swim lane diagrams of processes, and have stated that this example is available online. If you’re a Gartner subscriber, and interested in this, I recommended looking for the “Bank XYZ” example artifacts that they have. As someone hoping to look more into business architecture in the future, I think this material is going to be very useful.

Her final recommendations in the standard Gartner powerpoint template are:

• Don’t do the business architecture in a vacuum.

• Focus on interdependent business and IT viewpoints, aligned in the solution architecture.
• Use a multidisciplinary team approach.
• Business architecture is much more than process optimization.

I just finished my panel discussion with Mel Greer and Mike Kavis on measuring the value of SOA. I think we all had hoped that there would be more attendees, but hopefully those that chose to attend got something out of it. My main message was measure, measure, measure. I think it’s difficult to put a direct value on SOA adoption, that is, one where you can say the value was directly as a result of SOA efforts, but it’s not difficult to put a contributory value on SOA adoption. In other words, we need to measure the way IT is contributing to the success of the company as a whole, and as part of that, we can see some before and after measurements to see the impact of SOA and any other changes. The two things that I brought up in answering questions that I thought I’d share here are:

• Instrument your services now. Part of the problem with measuring things today is that we haven’t instrumented things in the past. These days, value is almost always expressed in relative terms, such as “relative to what we’re doing now.” If you’re not collecting metrics, you can’t say what “now” is, though. Once again, we’re at one of those unique opportunities where the door is open to do things differently. Put the instrumentation in now, before you have a portfolio of 100+ services that have no instrumentation.
• Measuring puts the spotlight on you, but will always enable you to answer questions better than before. A member of the audience asked the question, “What happens if your measurements show that you’re not achieving your goals?” This was a great question. Unfortunately, sometimes by the mere act of measuring things, people will immediately put the blame on you when things aren’t achieving the desired benefits, simply because you’re the one thing that can concretely demonstrate contribution (or lack thereof). My answer to this was two-fold. First, it was to try to make sure you have the backing metrics to allow proper root cause analysis. If you just focus on one metric, and nothing else, it makes root cause identification very difficult, and it puts the spotlight at the one area when you’re measuring. This puts strategic initiatives like SOA at risk, because people will think the whole thing is flawed, when in fact, the lack of results may have nothing at all to do with SOA adoption. Second, I talked about the appropriate spin to put on it, this being the political season in the US. When something doesn’t work out as planned, the way to spin the metrics is to show that we’re in a better spot to fix the problem because of the measurements than we would have been before.

The final thing I wanted to call out was a reference to a blog I posted yesterday at the request of Rob Eamon. Someone asked a question about how to get the stated goals from “the business” and the role of IT in contributing ways of measuring it. I called out that IT is part of the business, so there’s no reason that IT can’t contribute to the definition and appropriate ways to measure the business goals. Rather than viewing it as an “extraction” effort, it should be a joint effort with all members of the business, which includes IT.

If you attended the session, please feel free to post any comments or questions here. I hope it was valuable.

Frequent commenter Rob Eamon suggested a topic for me, hopefully he won’t mind me copying his email verbatim here:

One term that is starting to bug me more and more is “the business.” There is an implicit definition about this group and in IT circles that group is almost always referred to as “they.”

“That’s for ‘the business’ to decide.”
“We need to touch base with ‘the business’ on that.”

IMO, this tends to reinforce divide between groups.

So what exactly is “the business?” Why is IT typically assumed to be excluded from this group? Aren’t all groups in the company part of “the business?” Why do so many refer to “the business” as “internal customers?”

Smaller companies seem to embrace this seemingly arbitrary division much less so than do large companies.

I’m with you Rob. Many organizations have a separation between IT and everyone else, and even worse, it’s always IT referring to everyone else as “the business,” versus the non-IT staff treating IT as if it weren’t part of the company (although that happens too).

Part of the challenge is that IT works with nearly everyone outside of IT, and there isn’t a good term to describe them as a whole. Unfortunately, you hit the nail on the head. By referring to them as “the business,” there’s an implication that IT is not part of “the business.” It’s a shame that this is the case. I remember back in my days of focusing on usability where I had the opportunity to work on a cross-functional team with members of the Internet marketing group on an application. It improved things tremendously when we were able to work as a team, rather than as “the business” and IT. Unfortunately, this still tends to be the exception rather than the norm. So what should we do? Well, I don’t think we need another term to use. What we should be doing is getting off of our IT floors, and actually learning about the rest of the business. When we need to refer to a group outside of IT, refer to the group by their organizational name. If the application is for marketing, don’t call them “the business,” call them marketing. If it is for HR, call them HR.

One other question Rob asked was around the notion of “internal customers.” Like him, I don’t like the customer metaphor when talking about internal IT. The scary thing is, if IT had more of a customer service mentality, things would actually be better. The fact is, IT doesn’t have a good track record of customer service. We get away with lousy service because we’re part of the business. If we were an outsourcing company, we probably would have been shown the door a long time ago. IT should be better, not worse, than an outsourcing group. The only way to achieve this, however, is to get everyone in the company operating as a team, and continuing to emphasize that team mentality. It’s far too easy to get away with poor behavior with those you know, because the ramifications are usually less. As a testament to this, I think of my kids. First off, they’re great kids. But, if you’re a parent, I’m sure you can relate to this. My kids typically have excellent manners when dealing with the parents of their friends. When they come home, though, manners can be forgotten at the door. From a ramifications standpoint, my wife and I would probably be much more upset if they took out a bunch of toys at their friend’s house and didn’t help clean them up than if they took them out at our house and didn’t clean them up. Wouldn’t it be great if we had consistent behavior at both?

Part of this is human nature. This is why the “team” mantra must be something that is continually communicated over and over. The company I work for has a huge emphasis on safety. Not a day goes by without safety being brought up in some discussion. If they were to stop communicating about safety, I’m sure the behavior would eventually trend toward less safety. The same holds true for a team mentality. You can’t spend one year emphasizing teamwork and expect everything to stay that way when you stop. If teamwork is important, make it a part of everything you do, and keep it a part of everything you do. If you want to start from a grass roots effort and you work in IT, stop using the term “the business.” Instead, find out what group in the business you’re referring to, and use their name. I know I still use that term on many occasions, so I’m going to eat my own dog food and try to improve from here on out.

Presenter: Anthony Bradley

Anthony’s going to present Gartner’s new framework for building SOA business cases. He immediately began by stating that you can’t build a general business case for SOA. Rather, the point is to build an SOA business case for a particular business need. I can tell it’s the end of the day, as my attention span is dwindling quickly. This framework presentation is having the same impact on me as when I was first introduced to RUP. It appears to have a level of detail that makes it difficult to digest. The other thing that hasn’t been immediately apparent to me is why this isn’t a framework for building IT project business cases in general, rather than just SOA business cases. I’ll have to dig into the notes on this one, but right now, I’m a bit skeptical.

One of the things I recently started thinking about was the relevance of social networking sites like Facebook, Myspace, Plaxo, LinkedIn, etc. have to enterprises. While there are certainly individual usage of these sites, is there a play for the enterprise? Ann All of IT Business Edge, had a post about two weeks ago titled, “Facebook Not So Useful as a Business Tool,” quoting a study from Flowing Data that “just a tiny percentage of Facebook’s 23,160 applications are business-oriented.” In the comments that followed, one reader named Peter stated “businesses should take a serious look at integrating social media in their marketing strategy.”

The more I thought about this, the more I agree with Peter. If your company has individuals as either direct or indirect customers, I’m sure that the marketing department has segmented them into different groups each with their own strategy for how they will be marketed. I don’t know of any enterprise of significant size in the U.S. that doesn’t have an internet presence, and I’m willing to bet that nearly all of their marketing departments see their web sites as more than just a place to get electronic versions of paper documentation or marketing materials. In other words, the web site has gone through three phases.

1. The Information Web: In this phase, everything revolved around pushing information out to the visitor.
2. The Transaction Web: In this phase, the communication is bi-directional, predominantly focused on information from the enterprise, and business (i.e. money) coming from the visitor.
3. The Participatory Web: Here, the emphasis shifts from the individual to the community. It’s not just the enterprise pushing information out, it’s the full ecosystem all of the site visitors and all of the enterprise’s partners.

The big challenge with this third phase comes down to community. When an enterprise tries to own the community, it will probably work very well for established customers, but it may have a hard time bringing in new members. In contrast, a site focused on enabling communities of all sorts, like Facebook or MySpace, is better positioned for community growth. If this is the case, why wouldn’t an enterprise try to involve these sites in their marketing strategies as a growth tool. The point would not be to own the community, but to attract new members to its community. This is no different than the physical world where a company establishes a branch office or a retail location in a community. It has to compete with others, but at the same time, if it is perceived as valuable and meeting the needs of the community, it will survive and thrive. The time is ripe is to think about how your company can build applications and content for these sites to attract new interest.

I had the opportunity to attend a great presentation from Stephen Young, Founder and Senior Partner of Insight Education Systems. The talk was around the concept of micromessaging, which can be further broken down into MicroInequities and MicroAdvantages. To understand these, Stephen started with the difference between denotation and connotation. Denotation represents the words we use, while the connotation behind those words reveals the true meaning of what is being said. This can involve body language, inflection, tone of voice, and much more. As he pointed out, humans (or humanoids) have been communicating for hundreds of thousands if not millions of years. The written word has only been around for a fraction of that time. Therefore, so much more about how and what we communicate is conveyed by more than just the words. He did an exercise with us where we tried to describe what a dog does when it is happy. While most dog owners know within a fraction of a second the mood of their dog when they walk in the door, trying to convey that recognition process to someone else solely through words is incredibly difficult. In other words, our brains are very well tuned to picking up on things outside of the words in a conversation.

Getting back to the concept of micromessaging, MicroInequities are all of the very small things that we do in a conversation that have negative connotations, such as folding your arms, losing eye contact, giving a “ho-hum” response to the work of some individuals while lavishing excessive praise to others when the outcome of each was similar, etc. In contrast, MicroAdvantages are positive micromessages. The FAQ at the Insight Education Systems page does an even better job of explaining this. A very simple example of MicroInequities was the use of apologies in the workplace (and elsewhere). How often have you heard someone say, “If I offended you, I’m sorry.” Right off the bat, the use of the word “if” makes it a qualitative apology, and not a sincere one. Stephen said, “If you step on someone’s foot, do you say, ‘If that hurt, I’m sorry?’ No, we simply say, ‘I’m sorry.'” He used the example of Michael Nifong, the former attorney in the Duke lacrosse team case. His apology contained this:

To the extent that I made judgments that ultimately proved to be incorrect, I apologize to the three students that were wrongly accused. I also understand that, whenever someone has been wrongly accused, the harm caused by the accusations might not be immediately undone merely by dismissing them.

Analyzing this, we see that the apology immediately starts out with a qualifier. It then uses the terms “that ultimately proved to be incorrect” which connotes “I still think I was right.” His apology is only directed at three students, who he does not name, which excludes the impact to Duke University, the coach who lost his job, the team who lost their season, the families of the players, etc. On top of that, he didn’t even show enough respect to mention the players by name. The gist of this was that apologies should be about the impact, not the intent.

The talk went on to demonstrate the impact of our body language when listening and how it causes speakers to behave differently even when conveying the same or similar information, as well as the differences (and similarities) in different areas of the world. Already today, I have stepped back and adjusted the wording in an email I was composing as a result of this talk. I plan on putting his book on my Amazon wish list and encourage all of you to do the same, and, if you have the chance, hear him speak or bring him to your organization for a workshop.