Todd Biske: Outside the Box

Archive for the ‘Communication’ Category

I attended a presentation from Raul Camacho from the SOA Solutions group of Microsoft Consulting Services yesterday. The talk provided some good details on some of the technical challenges associated with lifecycle events associated with services, such as the inevitable changes to the interface, adding new consumers, etc., but I actually thought it was pretty weak on the topic. I thought for sure that I had a blog post on the subject, but I was surprised to find that I didn’t. Some time ago (January of 2007, to be specific) I indicated that I would have a dedicated post, but the only thing I found was my post on product centered development versus project-centered development. While that post has many of the same elements, I thought I’d put together a more focused post.

The first point, and a very important point, is that the service lifecycle is not a project lifecycle or just the SDLC for a service. It is a continuous process that begins when a service is identified and ends when the last version of a service is decommissioned from production. In between, you’ll have many SDLC efforts associated with each version of the service. I presented this in my previous post like this.

Raul’s talk gave a very similar view, again presenting the lifecycle as a circle with an on-ramp of service identification. The activities he mentioned in his talk were:

• Service Identification
• Service Development
• Service Provisioning
• Service Consumption
• Service Management

There’s many similarities between these two. We both had the same on-ramp. I broke out the SDLC into a bit more detail with steps of release definition, development, testing, and deployment, while Raul bundled these into two steps of development and provisioning. We both had management steps, although mine labeled it as the triple-M of monitoring, marketing, and management. The one key difference was Raul’s inclusion of a step of service consumption. I didn’t include this in my lifecycle, since, in my opinion, service consumption is associated with the lifecycle of the consumer, not with the lifecycle of the service. That being said, service consumption can not be ignored, and is often the event that will trigger a new release of the service, so I can understand why one may want to include it in the picture.

The thing that Raul did not mention in his talk, which I feel is an important aspect, is the role of the Service Manager. We don’t need Service Lifecycle Management if there isn’t a Service Manager to manage it. Things fall apart when there isn’t clear lines of responsibility for all things about a service. For example, a frequent occurrence is where the first version of a service is built by a team that is responsible for both the initial consumer and the service. If service ownership and management falls to this team, it is at best a secondary interest, because their real focus was on the delivery of the service consumer, not of the service itself. A second approach that many organizations may take is to create a centralized service team. While this ensures that the ownership question will get resolved, it has scalability problems because centralized teams are usually created based upon technical expertise. Service ownership and management has more to do with the business capability being provided by the service than it does with the underlying technologies used to implement it. So, once again, there are risks that a centralized group will lack the business domain knowledge required for effective management. My recommendation is to align service management along functional domains. A service manager will likely manage multiple services, simply because there will be services that change frequently and some that change infrequently, so having one manager per service won’t make for an even distribution of work. The one thing to avoid, however, is to have the same person managing both the service and the consumer of a service. Even where there is very high confidence that a service will only have one consumer for the foreseeable future, I think it’s preferable to set the standard of separation of consumer from provider.

So, beyond managing the releases of each service, what does a service manager do? Well, again, it comes back to the three M’s: Monitor, Market, and Manage. Monitoring is about keeping an eye on how the service is behaving and being used by consumers. It has to be a daily practice, not one that only happens when a red light goes off indicating a problem. Marketing is about seeking out new consumers of the service. Whether it’s for internal or external use, marketing is a critical factor in achieving reuse of the service. If no one knows about it, it’s unlikely to be reused. Finally, the manage component is all about the consumer-provider relationship. It will involve bringing on new consumers found through marketing and communication which may result in a new version, provisioning of additional capacity, or minimally the configuration of the infrastructure to enforce the policies of the service contract. It will also involve discussions with existing consumers based on the trends observed through the monitoring activity. What’s bad is when there is no management. I always like to ask people to think about using an external service provider. Even in cases where the service is a commodity with very predictable performance, such as getting electricity into your house, there still needs to be some communication to keep the relationship healthy.

I hope this gives you an idea of my take on service lifecycle management. If there’s more that you’d like to hear, don’t hesitate to leave me a comment or send me an email.

James McGovern frequently uses the term “perception management” in his blog, and there’s no doubt that it’s a function that most enterprise architects have to do. It’s an incredibly difficult task, however. Everyone is going to bring some amount of vested interests to the table, and when there’s conflict in those interests, that can create a challenge.

A recent effort I was involved in required me to facilitate a discussion around several options. I was putting together some background material for the discussion, and started grouping points into pros and cons. I quickly realized, however, that by doing so, I was potentially making subjective judgements on those points. What I may have considered a positive point, someone else may have considered it a negative point. If there isn’t agreement on what’s good and what’s bad, you’re going to have a hard time. In the end, I left things as pros and cons, since I had a high degree of confidence that the people involved had this shared understanding, but I made a mental note to be cautious about using this approach when the vested interests of the participants are an unknown.

This whole space of perception management is very interesting to me. More often than not, the people with strong, unwavering opinions tend to attract more attention. Just look at the political process. It’s very difficult for a moderate to gain a lot of attention, while someone who is far to the left or far to the right can easily attract it. At the same time, when the elections are over, the candidates typically have to move back toward the middle to get anything done. Candidates who are in the middle get accused of flip-flopping. Now, put this in the context of a discussion facilitator. The best facilitator is probably one who has no interests of his or her own, but who is able to see the interests of all involved, pointing out areas of commonality and contention. In other words, they’re the flip-floppers.

I like acting as a facilitator, because I feel like I’ve had a knack for putting myself in someone else’s shoes. I think it’s evident in the fact that you don’t see me putting too many bold, controversial statements up on this blog, but rather talking about the interesting challenges that exist in getting things done. At the same time, I really like participating in the discussions because it drives me nuts when people won’t take a position and just muddle along with indecision. It’s hard to participate and facilitate at the same time.

My parting words on the subject come from my Dad. Back in those fun, formative high school years as I struggled through all of the social dynamics of that age group, my Dad told me, “you can’t control what other people will do or think, you can only control your own thoughts or actions.” Now, while some may read this and think that this means you’re free to be an arrogant jerk and not give a hoot what anyone thinks about you, I took it a different way. First and foremost, you do have to be confident in your own thoughts and beliefs. This is important, because if you don’t have certain ideals and values on who you want to be, then you’re at risk for being someone that will sacrifice anything just to gain what it is you desire, and that’s not necessarily a good thing. Second, the only way to change people’s perception of you is by changing your own actions, not by doing the same thing the same way, and hoping they see the light. I can’t expect everyone to read the topics in this blog and suddenly change their IT departments. Some may read it and not get it at all. Some may. For those that don’t, I may need to pursue other options for demonstrating the principles and thus change their perceptions. At the same time, there will always be those who are set in their ways because they have a fundamental different set of values. Until they choose to change those values, your energy is best spent elsewhere.

A previous post discussed how no two organizations seem to define the role of the architect the same way. It just occurred to me that the same thing holds true for another common deliverable of the enterprise architect: the reference architecture. I’ve had the opportunity to work on a few reference architectures with a few different companies and I can certainly say that no two were the same, although there was certainly commonality between them.

There are at least two questions that have come up in multiple efforts. The first is whether or not a reference architecture should recommend specific technologies (e.g. “if you meet these conditions, you should use vendor product MagicFooBar”) or only describe the capabilities required, leaving implementations teams to choose a technology that fits (e.g. “the services tier must be exposed using XML-based interfaces”). The second question is one of depth. How much guidance should a reference architecture give? Should it go so far as to place constraints on how individual classes are named, or how the file hierarchy is set up in the source code repository? Or should it remain at a level somewhere above the design of individual classes? It may seem simple at first glance, but I can speak from experience that once you start providing some guidance, it’s very easy to get pulled into the depths.

What’s the right answer to these questions? I don’t think there is one. Why? Because reference architecture is about guidance, and the guidance needed in any one particular organization is going to be dependent on the skills of the staff, the organizational structure, the technologies involved, the problems being solved, etc. So what do you do? In my opinion, a good course of action is to focus on delivering guidance that is singular in purpose, at least within a single deliverable. What does this mean? It means that you should avoid trying to answer all of the questions within a single (and likely very large) document. Rather, each deliverable should start with one simple question, and focus on answering that question clearly. For example, rather than having one big reference architecture that attempts to cover all possible business solutions which could easily include web UIs, desktop UIs, mobile UIs, workflows, services, automated processes, applications portals, content portals, collaboration portals, and much more, consider having a separate document for each one, forming essentially a hierarchy of documents. The earlier documents discusses things more broadly, intending to answer the question of what collection of technologies are needed for a solution, but not necessarily guidance on the appropriate way to use that technology. For that, once the decision to use a particular technology has been made, a separate document goes into added depth, and the process continues. The reference material will eventually work its way down to development and operational guidelines (or hook up with those that may already exist).

Of course, all of this is easier said than done. It’s not easy to determine the “right” hierarchy up front. Again, the litmus test to apply is whether the document has clarity and singularity in purpose. If you find yourself with a document that starts getting onerous to use, consider breaking it apart.

What are others thoughts on this? As always, this is simply my opinion (after all, this is my blog, so that’s what you’re going to get), but I also am always interested in the thoughts of others and striving for a more collective wisdom. What has been successful for you when trying to provide reference guidance to teams? What hasn’t been successful? Use comments or trackback.

Update: I was just checking my feeds and there were two others blogs that discussed reference architectures: this one from George Ambler and this one from Simon Brown. Enjoy.

Mike Kavis asks the question, “Why are you still generating reports?” In his blog, he states that “we should empower the users to create their own reports.” This brings up an interesting discussion. Anyone who has worked in IT for a few years know that there’s a significant amount of work that is done using Excel. Excel is the empowered user’s tool of choice. Is this a good thing or a bad thing? On the one hand, individual users are empowerd. On the other hand, is the analytics being performed of value to more than just that user? Could someone with a computational background perform those same analytics in a much more efficient manner?

The statement that Mike makes for which there is absolutely no argument against was this one:

When users ask for a report, the business analyst must ask the user, “What problem are you trying to solve?”

Ultimately, IT and the power user should be collaborating on what the best solution is. The user may have a need for ad hoc analytics, but there should also be a way that those analytics come back into the fold and are available for broader use. If the power user wants IT to simply get out of the way or IT simply wants to maintain tight controls on information, that’s a sign of an unhealthy relationship. Rather, both parties should be concerned with leveraging each other’s strengths to the fullest extent to create the best solution.

James Taylor (not the singer) posted a followup to Mike’s blog that makes similar points. He also suggests that we dig into the reasons behind the request for information. Given his focus on enterprise decision management, he suggests focusing on the decision that the person was trying to make, rather than on the information used to support that decision. The key similarity between my message, Mike’s, and James’ is that we need to go beyond the initial request and understand the purpose behind it. Odds are that there’s something else that IT can be helping out with.

James McGovern called out that he hasn’t seen much discussion on the topic of reference architectures, and called me out for my thoughts. I’m never one to pass up a good blog topic, especially when I don’t have to come up with on my own.

First, some background on my experience. My current job responsibilities include the development of reference architectures, my engagements with clients while I was a consultant all included the development of either a deliverable that included “reference architecture” in the title, or was clearly some form of reference material, and my job prior to consulting, included the development of reference architectures within the last 12 months of my time there. So, I’m no stranger to this space.

Reference architectures, and reference materials (since the need doesn’t stop at architecture) in general are an interesting beast. Personally, I view them as part of the overall governance process, mainly because they’re created to document a desirable pattern or approach that the authors would like (or will ensure that) others follow. At the same time, a document alone does not create governance, just as buying an SOA Registry/Repository doesn’t create SOA governance. Reference materials are a tool in the arsenal and the degree to which they are used is dependent on how you architects work with the end consumer of the reference material. Organizations are all over the spectrum on this. Some architects live in an ivory tower with virtually no interaction with teams on active projects, some architects are the exact opposite, with their time completely consumed by day-to-day project activities. Most organizations fall somewhere in between.

My opinion is that reference material is absolutely necessary, if nothing else but to prevent the organization from tribal operations. If none of the standards and guidelines ever get written down, and decisions are solely based on tribal knowlege, the organization can quickly break down into the haves and the have-nots. If you’re part of the tribe, you have the knowledge. If you’re not, all you can do is make your best guess until you have to show up to tribal council and get lambasted. Trying to gain the knowledge from the outside is a very difficult process.

The next question, however, is what information belongs in the reference material? Does it do any good to document something in the reference architecture that everyone should already know, or should you assume that no one knows anything, and document it all? The problem is that EA has limited resources, just like everyone else, so you have to give consideration to the bang for the buck in the reference material. Once again, what’s “right” is very dependent on the end consumer of the material (which is why having a consumer focus is important). If you have an organization of seasoned Java programmers, how much reference material is needed on developing good web applications? If you have an organization with lots of VB6 and COBOL developers, they may need lots of reference material on web applications. So, know your audience, and make sure that the reference material is relevant and valuable for them.

In this session, Robert Handler is giving a talk entitled Communication, Persuasion, and Interpersonal Skills for EA. In a previous job, I worked with someone who was passionate about communications. He helped us create a communication plan around SOA and our competency center, and I really think it made a huge difference in our efforts, so I had a keen interest in this topic. I’ve previously blogged on some of the subjects in this presentation, including my Focus on the consumer entry.

Robert is spending a lot of time talking about Marketing and Sales, which is a great approach for this subject. For example, one task in marketing is identifying and segmenting it. Robert correctly points out the different segments for EA (senior leaders, business unit leaders, IT leaders, and IT groups) all want different things. Great point. I’ve met many technical people who want to create one thing and expect that everyone will see the inherent value in it when there hasn’t been any effort to tailor it or present it according to the differing needs.

He’s also spoken about creating the delivery system. Are you going to use a web portal? Wikis? Think about how your EA deliverables will be sent out to your markets. He’s also addressed branding and its importance.

On the sales side, he’s begun with a discussion on stakeholder analysis, and a detailed level at that. Again, it’s about understanding how to communicate and sell to the particular personalities and how they make decisions. Do they want a lot of detail? Do they want structure? Do they want to hear more about people and social issues, or do they want specific tasks? Again, there’s no one approach, it’s about matching the right approach to the right person.

He’s now talking about persuasion, and presenting techniques from the work of Dr. Robert Cialdini. He defines persuasion loosely as getting people to reply to your requests. The principles associated with persuasion include:

• Contrast principle: You can change the way someone experiences something by giving them a contrasting experience first.
• Principle of reciprocation: people feel obligated to give back somethign similar to what was given to them.
• Principle of scarcity: People want what they can’t have.
• Principle of authority/credibility: People defer decisions to experts, legitimate or otherwise.
• Principle of trust: Admit a flaw or weakness to show you are trustworthy.
• Principle of consistency: People want consistency and to be viewed as consistent.
• Principle of liking: People like those who like them, pleasant associations is the same as liking, people say yes to those who they believe are cooperating.

Message: keep these principles in mind as you sell EA. For example, he told us about a group that had little badges with LED lights that were given to projects that worked well with EA. The EA team was very stingy with them, however, adhering to the principle of scarcity. The result was that teams worked that much harder to be compliant, because they wanted these $2 badges that they could have ordered from Oriental Trading Company.

I’ve been really impressed with both of Robert’s sessions that I’ve attended. I’ve have to look into more of his research and recommend that other Gartner clients out there do so as well.

It has been a couple years since I attended a Gartner Summit, and now I’m remembering past experiences. Many of the subjects are presented at a very high level (which is appropriate for the audience at a Gartner conference), and many of the subjects are ones that I’ve spent a lot of time researching on my own. I’ve been trying to attend more sessions this time on subjects that I don’t know much about, so the experience has been better. What I’m wondering, however, is why more of the people attending (and there are easily more than a thousand of them) don’t start reading my blog and that of my colleagues in the industry to pick up this knowledge (in addition to attending conferences like Gartner Summits) and even more importantly, ask questions. Yes, reading my blog doesn’t allow you to travel to some interesting location, but I like to think that the content I provide is appropriate and meaningful.

I hear many questions getting asked over and over at these conferences, and it’s apparent that there’s a very large group out there that simply don’t look for the answers to their questions beyond these conferences. Rather than look for the information, they look for an information source. Guess what folks, this is the information age, and there’s a wealth of it out there. I built up my knowledge not only with research from Gartner, Forrester, Burton Group, ZapThink, and others, but also by reading whitepapers, articles, blogs, and anything I could get my hands on. You can do it as well. Gartner, my blog, conferences, webinars, etc. are all sources of information, and the most important thing is to find information that hits home for you and seems applicable to your environment. If it’s one case study instead of one hundred, it doesn’t matter, as long as it is relevant to your scenario, not someone else’s. Gartner is an excellent source of information, and I like to think that this blog is as well. Use both, and then some, and lets keep things progressing forward so at next year’s Gartner conferences we’re talking about new questions, rather than rehashing the same ones.

James McGovern responded to my Certified Architect

post with one of his own. He made a great point at the end of his entry which was something I wanted to discuss in my original post but didn’t find a way to work it in. He stated:

I guess the point that I am attempting to make is that certifications are neither good nor bad, and it is important to look at each within the context of the role you expect this individual to play. It is my belief that certifications don’t prove hands on skills at all, but having multiple at least says that there is evidence as an Enterprise Architect that you have the ability to learn as well as the desire…

Personally, I think the ability to learn, and learn quickly, is a critical skill for an architect. While some may think that architects spend all of their time up in clouds working on strategies and reference architectures, many of the architects I know are the go-to people when projects are struggling with decisions and direction. An architect needs to be able to quickly understand what it is that project is trying to do, determine what the most critical factors are, and provide appropriate guidance. At other times, it may not be the tactical project, but rather the senior executive asking the question, “should we be paying attention to any of this Web 2.0 and Social Networking hype?” The architect must quickly develop enough knowledge to make good decisions. Probably all architects will get stung at some point by some lower-level detail, but the good architects probably also take it in stride because they’re always learning.

When I interview people, I always ask a question about how the individual stays current, and it’s amazing how many people struggle with that question. If you’re not taking the time to learn, you’ll get left behind. I hope the readers of this blog learn things, and that’s a big reason why I do it. It’s even better when I get comments, links, or trackbacks, because I’m able to learn as well.

Nortel and IBM recently announced joint technology for integrating business applicaitons with communication services (InfoWorld article, SearchSOA article). Personally, I’m glad to see this announcement. I first had conversations around communications services with a colleague back in early 2006. He was looking at the future state communications infrastructure and came to me wanting to know how to make sure it would fit in with SOA. I had never thought about this before, but it made perfect sense. Communications, clearly, is a capability, so why shouldn’t those technical capabilities be exposed as services? Kudos to Nortel for having a press release about this and really emphasizing how this can play in a company’s SOA is a win in my book. While I’m sure other vendors in the communications space also have these capabilities, they’re not emphasized. As a result, it creates an atmosphere for more silo-based thinking around point-to-point integrations, rather on how this capability fits into the broader collection of enterprise capabilities.

The field of communications would also probably make a great case study or research project. If someone were to try to define communications services 10 years ago versus today, you’d have a very different collection. Would a presence service even be mentioned? Would it have been voice only, or would it have involved text/instant messaging, email, and/or video as well? It certainly makes the case for active service lifecycle management versus defining the services once and then moving on to the next project. As you define your service domains, you have to recognize that the definitions of those domains and even the collection of domains themselves will change.

Richard Monson-Haefel announced an upcoming telebriefing from the Burton Group that will ask the question, “Is the iPhone ready for the Enterprise?” I think this is going to be a very interesting discussion, and hopefully Richard will post a summary of the discussion after the fact for those of us that aren’t able to listen. It should be a great conversation, as they’re bringing analysts in from various services for the discussion.

Interestingly, with all of this talk about the iPhone and the enterprise, I actually think we’re asking the wrong question. It’s not about the iPhone, rather, it’s about how connected, mobile devices should be leveraged in the enterprise. Certainly, there are plenty of industries where mobile devices already play a key role. Just look at the technology associated with any company in the logistics industry for examples. The real discussion, however, is for those industries where the use of connected, mobile devices may not be immediately apparent. There are many enterprises that still have desktop machines for all employees and are just beginning to look at whether laptops should be issued, let alone consider something like the iPhone. Therefore, there is potential for a disruption in this space, something that could have a fundamental difference in how we go about our tasks.

The reason this discussion is gaining such momentum now, in my opinion, has everything to do with the full-browser capabilities of the iPhone. While I didn’t own a smartphone before getting an iPhone, I did have some experience with a Blackberry (before they had phone capabilities), and made extensive use of the WAP browser on my old Motorola V360. Email and access from the Blackberry was great, but that’s about it. Now, we’ve got this full web browser that can run a variety of web based applications (although not all, my kids can’t play with Webkinz on it due to no Flash, which is probably a good thing, at least as far as playing Webkinz goes). There’s a whole range of applications out there, as Richard calls out, the real potential is in applications developed specifically for the iPhone. Is this any better than some of the custom apps for one of the other smart phones? I’ve never written a mobile app, and I don’t know what limitations they have when the phone doesn’t have full web capabilities. I can only suspect that the recent hype on this subject is an indicator that only now have the doors really been opened. Connectivity is critical to these devices, otherwise they just become a PDA, which has certainly faded away. The question is whether connectivity + small form factor equals disruption. While I use the iPhone Facebook application, I’d hardly call it disruptive. There’s a killer app out there waiting to be written.

While I’m sure the conversation will focus more on the technical details around the iPhone in the enterprise, hopefully it will expand into the potential for mobile devices in the enterprise, whether it’s through a laptop with WiFi or wireless broadband or an device like the iPhone. Ultimately, this is what will decide whether it gets a place in the enterprise versus just being yet another way of getting to the corporate email and calendar.

The latest Briefings Direct: SOA Insights podcast is now available. In this episode, we discussed semantic web technologies, among other things. One of my comments in the discussion was that I feel that these technologies have struggled to reach the mainstream because we haven’t figured out a way to make it relevant to the developers working on projects. I used this same argument in the panel discussion at The Open Group EA Practitioners Conference on July 23rd. In thinking about this, I realized that there is a strong connection in this thinking and SOA. Simply put, it is all about the consumer.

Back when my day-to-day responsibilities were programming, I had a strong interest in human-computer interaction and user interface design. The reason for this was that the users were the end consumer of the products I was producing. It never ceased to amaze me how many developers designed user interfaces as if they were the consumer of the application, and wound up giving the real consumer (the end user) a very lousy user experience.

This notion of a consumer-first view needs to be at the heart of everything we do. If you’re an application designer, it doesn’t bode well if you consumer hate using your application. Increasingly, more and more choices for getting things done are freely available on the Internet, and there’s no shortage of business workers that are leveraging these tools, most likely under the radar. If you want your users to use your systems, the best path is make it a pleasant experience for them.

If you’re an enterprise architect, you need to ask who the consumers of your deliverable are? If you create a reference architecture that is only of interest to your fellow enterprise architects, it’s not going to help the organization. If anything, it’s going to create tension between the architecture staff and the developers. Start with the consumer first, and provide material for what they need. A reference architecture should be used by the people coming up with a solution architecture for projects. If your reference architecture is not consumable by that audience, they’ll simply go off and do their own thing.

If you are developing a service, you need to put your effort into making sure it can be easily consumed if you want to achieve broad consumption. It is still more likely today that a project will build both service consumer and service provider. As a result, the likelihood is that the service will only be easily consumable by that first consumer, just as that user interface I mentioned earlier was only easily consumed by the developer that wrote it.

How do we avoid this? Simple: know your consumer. Spend some time on understanding your consumer first, rather than focusing all of your attention on knowing your service. Ultimately, your consumers define what the “right” service is, not you. You can look at any type of product on the market today, and you’ll see that the majority of products that are successful are the ones that are truly consumer friendly. Yes, there are successful products that are able to force their will on consumers due to market share that are not considered consumer friendly, but I’d venture a guess that these do not constitute the majority of successful products.

My advice to my readers is to always ask the question, “who needs to use this, and how can I make it easy for them?” There are many areas of IT that may not be directly involved with project activities. If you don’t make that work relevant to project activities, it will continue to sit off on an island. If you’re in a situation where you’re seen as an expert in some space, like semantic technologies, and the model for using those technologies on project is to have yourself personally involved with those projects, that doesn’t scale. Your efforts will not be successful. Instead, focus on how to make the technology relevant to the problems that your consumers need to solve, and do it in a way that your consumers want to use it, because it makes their life easier.

SearchCIO.com recently had an article discussing blogging in the corporate world. I recently discussed the use of blogs and wikis inside the enterprise, this entry will focus on blogs that are exposed to outside world.

As James McGovern has lamented in the past, and Brandon Satrom recently, there really aren’t a lot of enterprise architects working in typical corporate IT blogging. By typical corporate IT, I mean at companies whose primary business is not technology. I don’t know if this carries over to other roles within IT, but I suspect it does. So, is this is a bad thing? A good thing? Some companies may have formal policies regarding blogging, some may not. It can be a complicated issue, however, I do think that there is one basic factor that comes into play, and that is trust. For the purpose of this conversation, I’m going to restrict it to where people are blogging about the domain in which they work. So, if you’re an enterprise architect, this is relevant if you want to blog about enterprise architecture. If you want to blog about your favorite TV show, less of this discussion applies.

From the perspective of the blogger, what are the reasons you’d want to blog? For me personally, my blog served two purposes. First and foremost, there are constantly ideas that go fleeting through my brain, and I wanted to use blogging as a way to record my thoughts. Secondly, I wanted to share those thoughts with others and see what conversation came out of it. If others found it valuable, that’s great, however, I don’t go around trying to look for topics that I know may have high market value. This may not be the case for others. Some may go out trying to capture the spotlight as a primary goal. There are those that argue that everyone who blogs is seeking the spotlight, but I don’t believe that to be the case. One thing that is true, however, is that if you blog, you are building a brand, whether you planned to or not. This is where things can get complicated.

Most companies are usually very sensitive about how they are perceived in their respective marketplace, regardless of whether they have a formal branding or marketing initiative or not. The real danger comes when someone can make an association between you and a company, and as a result, make associations between the two. Take the current situation with Michael Vick. While the NFL and Atlanta Falcons had no control over his off the field activities, there are now significant problems with not only his personal brand, but the brand of the NFL and the Atlanta Falcons. While the blogosphere isn’t usually under the same level of scrutiny as professional athletes, the impacts can be very similar. As an employee of a company, you have to realize that as a privately held (even if publicly traded) institution, you must abide by their rules, even if it is activities that you are doing with your own equipment, and on your own time. I’m not a lawyer, but most organizations do have some form of personal conduct policy that can apply. If you’re not officially blogging for your company, it’s best to try to keep the worlds as separate as possible.

For me, I looked upon my topics like a water cooler conversation. If I felt that I could discuss a subject at a local user group meeting, or over lunch with colleagues at a conference, or even on a discussion group (keep in mind that Google can typically find all of those discussion group postings…), then those topics would be okay for a blog. Specifics about the internals of a company were (and still are) strictly off limits. I personally believe that we can learn a lot from our colleagues at other enterprises, and there’s far more we can share without comprising any competitive advantage, than there is at risk. For example, take a blog on something like service versioning. There really shouldn’t be any concern about competitive advantage when discussing something like this, something every enterprise will have to deal with, etc.

It is unlikely that your company has a policy that makes these things clear cut. It’s especially difficult when the company may come back with the question, “What’s in it for us?” It’s hard to put value on something like blogging and it will ultimately come down from trust. If you’re going to blog, get quoted in a magazine, speak at a conference, etc. there has to be a level of trust. The company has to trust that you will represent the company well, even if you’re only speaking about them in generalities. The fact is, you are part of that company and will be perceived as a representative of that company. If you’re a shock jock at night, that doesn’t bode well if someone finds out that your day job is with a very conservative company. Even if there’s no mention anywhere in your blog of the company you work for, it’s not very hard to figure it out. For example, I know where James McGovern works, even though you won’t find it on his blog.

The short of this is that there has to be a level of trust, and probably more so on the side of your employer, which is an unfortunate fact of our culture today. As I’ve mentioned, there’s a certain fear of airing your dirty laundry. As anyone who has worked in multiple enterprises know, there are plenty of things that need improvement, and many of them probably have nothing to do with competitive advantage. A little bit of transparency and a little bit of open discussion can go a long way in building trust. That being said, you’re better off focusing on building trust inside the enterprise first. If you want to open up a conversation on a topic, why not open it up inside the enterprise first and let your colleagues have a crack at it, even if it may not be their responsibility? Good productive communication will build trust, which in turn, will make the company more likely to trust that people know what can not be communicated to the outside world and what can.

I was listening to an Inflection Point podcast from the Burton Group entitled Enterprise 2.0: Overcoming Fear of Blogs and thought that this was a subject that I hadn’t posted anything about. The topic of the podcast was the use of blogs and wikis internally within the enterprise, rather than enterprise workers blogging to the outside world, which is a different subject.

The interviewer, Mike Gotta, made the comment that blogs within the enterprise need to be purposeful, and that there’s a fear that they will simply be a soap box or a place to rant. To any manager or executive that has a fear about them becoming a place for employees to rant, you’re looking at the wrong issue. If employees feel a need to rant, they’ll be doing it in the hallways, break rooms, and cafeteria. If anything, blogging could bring some of this out in the open and allow something to be done about it. This is where I think there is real value for blogging, wikis, etc. in the enterprise. I recently had a post titled Transparency in Architecture that talked about a need for projects to make their architectural decisions transparent throughout the process (and the same holds true for enterprise architects and their development of reference architectures and strategies). Blogs and wikis create an opportunity to increase the transparency in enterprise efforts. I’ve worked in environments that had a “need to know” policy for legitimate reasons, but for most enterprises, this shouldn’t be the case. When information isn’t shared, it may be a symptom of lack of trust in the enterprise, which can be disastrous for SOA or anything else IT does.

Blogs and wikis are about communication and collaboration. Communication and collaboration help to build up trust. That being said, you do need to be respectful of the roles and responsibilities within the organization. There’s a time and place for debate, and there’s a time and place for adherence to policies. I’ve been in the trenches and had my fair share of times where I didn’t agree with a decision that was made by people above me in the organization. I also understood that it wasn’t my decision to make. In general, however, I believe that things would have been better if there were transparency behind those decisions. That’s important because the principles that guide those decisions wind up influencing the decisions that are made further down the line. If the staff has no visibility to those principles, how can they be expected to make good decisions? The end result of that situation is increased distrust on both sides. It’s not easy to do, because once you expose that information, it leaves you open for debate, which is where mutual trust must come into play. Betrayals of trust either by not disclosing information or by misusing information that was disclosed can be detrimental.

In general, I’m an optimist and I give people the benefit of the doubt. As a result, I’m all for transparency and the use of blogs and wikis in the enterprise. Will blogs and wikis dramatically change the way IT works? Probably not, but it certainly has the potential to improve morale which certainly have a role in improving productivity.

Courtesy of Rich Seeley and SearchWebServices.com, I caught up with the recent announcement from IBM Rational at their IBM Rational Software Development Conference going on in Orlando.

Rich paraphrased David Locke, director for IBM Rational Worldwide Marketing Strategy, stating that “the next generation tools that the Jazz project is expected to create will aim at providing real-time collaboration of geographically dispersed project teams through things like embedding instant messaging technology into development tools.” There are a few things that occurred to me after reading this.

First, the idea of “open commercial” is quite interesting. IBM Rational still intends to develop “fully commercial” products, yet they’re doing it through a very open process. As long as the community doesn’t revolt on them for wanting their time without somehow sharing the profits, this could be successful. While I’ve never seen studies on it, I still suspect that the bulk of open source products are still strongly subsidized by paid staff of companies that are making money from it (e.g. IBM, MySQL). I’m sure IBM and BEA both have paid staffers who spend all of their time on Apache projects.

Second, the mention of instant messaging brought up recent memories for me. While I don’t think anyone has noticed, there’s a link at the top of this blog labeled “Talk to Me”. As an experiment, I put a Google Talk widget on the site. Unfortunately, it doesn’t work the way I’d like it to. Effectively, I wanted it to be pre-configured with a buddy list of me, without the ability to chat to anyone else, or maybe just to people visiting my blog. There wasn’t a way to do it. I looked into other systems, but didn’t find a way to integrate with my existing IM clients. To make Google Talk work, I had to post instructions on adding me to the buddy list, which isn’t that great of a solution. Anyway, my point with all of this is that it’s a big challenge on figuring out how to integrate all of these things. I was listening to the latest Monkcast from ZDNet and Redmonk and listening to the guys reminisce that at one time years ago, Microsoft Exchange was winning because of its simplicity. I will certainly agree that keeping things simple can be beneficial, but eventually there becomes a need to integrate all of these smaller, simple items into something that is more functional and efficient. Balancing those tradeoffs is not an easy problem. Here again, I think there is power in the masses and opening it up to the community. The last thing we need is an embedded and isolated IM client, and that’s just one example. Personally, I hope that the community looks into some of the lightweight capabilities provided by things like the MacOS X Dashboard and Vista Sidebar and see if we can get the simplicity of these low-functionality interfaces but yet allow “right-time” integration with the tools we’re using the majority of the time.

I was recently having a conversation regarding data services and my recent posts (here and here) on horizontal versus vertical thinking put it in a new light. My experience has shown me that data services are one of the most controversial topics within an enterprise.

Nearly all solutions, somewhere along the line, are going to need to access some form of structural data, typically from one or more relational databases. The debate around data services begins with a discussion on whether or not all access to the data should go through a service or not. I’m not going to get into that part of the debate in this post. The point of this discussion lies more with the organizational challenge of creating a data services layer.

One reason (but certainly not the only one) that is sometimes used to justify a data services layer is to maintain control over how the databases are used. All it takes is one bad SQL statement to cause a significant impact to all systems using that database. When organizations see this problem, the instinct is to centralize the development of data services. By creating a team with expertise in database access technologies, the assumption is that you’ll get high quality services that will prevent system failures due to data unavailability. The challenge with this approach is that this assigns ownership and service boundaries along a technical domain: data access. Per my previous postings, assigning ownership based on technical boundaries implies a horizontal domain. Horizontal domains are ones where the capabilities are becoming commodities and can be done in a standard fashion. Service teams in a horizontal domain typically strive to minimize the number of services involved. This is where the challenge occurs. Data access is anything but a commodity. While the techniques used to access data may be standardized (SQL), the structure of data and the combinations of data desired by consumers is certainly not.

In his book Human Interactions,
Keith Harrison-Broninski pointed out that everyone deals with information differently. We file it differently, we take notes differently. Trying to standardize information access is inherently problematic. Why is this? Because information retrieval operates in a vertical domain. We’re retrieving information for the purpose of doing a particular task. So, we have a services team that is viewing the world in a horizontal fashion, with their primary goal being to minimize the number of services they provide. On the other side of the equation, we have vertical thinking consumers that want data for a particular purpose in a format that is optimized for what they need to do. Clearly, if the consumers have the most influence, the goal of the service team to minimize the number of services is not going to happen. If the service team has the most influence, the goal of the consumers to have optimized services is not going to happen. We simply have a situation where the two (or more) teams involved have competing goals. You can’t say that either one is right or wrong, only that they are competing with each other. There can be sound justification on both sides, so the organization must mediate and try to create a win-win situation.

I think this subject is a great example of the concepts of horizontal and vertical thinking. Things can go very smoothly when both the consumer and provider are consistent with their understanding of a particular domain as either horizontal or vertical. When there is disagreement, and one group sees things as horizontal while another sees things as vertical, the relationship is going to be problematic. If you can make it a win-win situation, that is the best scenario. If one party or the other simply has a view that is inconsistent with the view of enterprise architecture, that’s a communications and education issue for EA. EA needs to set the policies for what constitutes good architecture, and if a particular functional domain is deemed to be horizontal (or vertical) that information should be well communicated so the individual solution architect approaches its usage properly.