Envisioning and shaping the future of work and business.

Tuesday, July 24, 2007

Practical Enterprise Architecture

I was bewildered when I first started working with Enterprise Architecture (EA). To me, so far, the subject had belonged to some strange guys working somewhere in a remote part of the enterprise. Once in a while, a decision or model came in the mail or were posted on the intranet with regards from those guys. Rarely anybody knew how to interpret the much too abstract or detailed directives, and consequently these directives were never followed. If you turned to them for some kind of advice, their advice was always delivered too late or was not applicable to the problem at hand.

The little example above is representative for a common esoteric approach to EA where only the few cult members of the EA team are able to decode or appreciate the runic messages and unworldly divinations. What constitutes a more practical and productive approach? Below are some short statements I once set up to find an alternative approach to EA.

  • Facilitate the continuous change of the business (do not model the past): EA is in essence about enabling business changes via supporting the evolution of key enterprise IT assets. Therefore, the business is the primary client for EA and it needs clear coaching in strategic planning, development and production. A common mistake is to try to model everything in detail. That will turn out a never ending mission.
  • Collaborate closely with the stakeholders (do not do it without power): The business and IT managers are the ones who make strategic decisions. EA should be a natural part of their discussions and decisions. But, to really make a difference EA must be something more than an interesting speaking partner. EA must be a function with a formal role in the business or IT governance organization. Otherwise, all changes must be realized by tiresome pleading and lobbying, resulting in frustration and possible burnout.
  • Manage stakeholders' expectations (do not do everything for everyone): Being successful in EA is related to if the stakeholders get what they require. Because of the vastness of the EA domain and the potentially many stakeholders, there is a need to prioritize to survive. Communicating clearly and openly about these priorities and what will be delivered will gain respect and realistic outlooks. If this is not done, the risk is that nobody will be happy with the deliverables, even if they are the results of heroic efforts.
  • Engage early in the process (do not wait until the bitter end): Being part of the decision process in planning (making the reasonably right things) and project initiations (making it reasonably right) creates the most business value and reduces the impact of later costly project predicaments and alterations. Coming to a project manager, with an already set timetable and budget, and suggesting major changes is seldom appreciated and fruitful.
  • Coach and communicate in accordance to maturity (do not do everything "by the book"): EA is about decision support. The supporting EA should make it easier for the stakeholders to make better decisions. So, make sure to use images and metaphors that are comprehensible for the stakeholders. Use and reuse simple illustrations that convey the essence needed to build trust in the stakeholders. Realize that it is a learning process and that transfer of knowledge will require a lot of time, effort and patience. Work from the top and down in small iterations and concentrate on showing the relationships between the core business processes and IT services.
  • Establish a good network with domain architects (do not do it without good friends): Good and knowledgeable colleagues are essential for making fast inquiries and qualitative indications and estimations. A lot of the EA work is about sketching out scenarios that show the big picture of suggested changes. A merger of two companies, consolidation of platforms, and the addition of new sales channels are examples of changes that will affect the existing IT assets. The network can be used for running quick workshops and brainstorming sessions which support management with the adequate information.

The above tactical guidelines may be relevant if an enterprise is new to EA or suffer from failed EA initiatives. The key point I am trying to make is that many enterprises would benefit from a more agile approach that is better adapted to the stakeholders’ needs and capabilities.

Friday, July 13, 2007

Information Management & Content Management

4:19:00 PM Posted by Oscar Berg , No comments
With the term "content" we refer to what is inside, what is contained within, something. When managing content, the key question to address is not what exactly is within the container, or what the purpose or goal of the content is. No, the key question is if the container provides us with enough information about how to manage and deliver it to the receiver (a human or machine) in an efficient and secure way. Like the postal service, those who have been assigned the responsibility to manage and deliver the content to the receiver should not need to open the envelope to read what the letter says in order to fulfil their responsibilities. Instead, there must be information on the envelope that tells them how to manage it and to whom and where, how fast and in what way to deliver it. Their job is simply to manage and deliver it to the receiver in an efficient and secure way. So, there you have Content Management in a nutshell.

Information Management, on the other hand, deals with the purpose of the content and its effects on the receiver. The key question to address in Information Management is if the message is delivered in the right time to the right person (not system), if the message is interpreted and understood correctly, and if it leads to the desired actions. The message is usually communicated via digital content, but it could just as well be communicated by other means, such as by voice in a person to person conversation, as long as it satisfies an information need. Because what really matters is the end result - that the right person got the right information in the right time and that it resulted in the desired actions. Information Management tries to ensure that this is done and in an efficient and secure way by employing the capabilities of modern information technology. But in the end, it is more about human-to-human communication than technology.

Content Management is a little more straight-forward than Information Management. Simply put, the postal service has done its job if it has securely delivered your letter to the receiver you wrote on the envelope in the right time. It cannot be held responsible if the letter was sent to the wrong receiver because you wrote the wrong name or address on the envelope, if you composed the letter in a way that the receiver could not interpret or understand the message correctly, or if the receiver understood the message but just didn't react to it as you wanted him/her to.

The fields of Business Intelligence, Document Management, Records Management and so on are all about both Content Management and Information Management. Although they are taking different perspectives on communication processes based on the type or nature of the content that is to communicate the message, they share the same goal - to ensure that the intended receiver(s) gets the right information or experience in the right time. In other words, they are all about Information Management. And, they are all about Content Management since the process (content) needs to be managed if the content is to be handled and delivered in a secure and efficient way to the intended receiver.

Monday, July 9, 2007

Will Enterprise 2.0 Help To Make Enterprises More Agile?

11:46:00 AM Posted by Oscar Berg , , , No comments
My interest in Enterprise 2.0 technologies is very much related to the question if and how they can help to make an enterprise more agile. With agile I mean the following:
  1. Ability to quickly anticipate, recognize and identify important changes (or need for changes) in the business environment

  2. Ability to quickly make informed decisions on how to react (or not react) on these changes

  3. Ability to quickly react on the changes by adjusting goals, strategies, processes, organization and supporting infrastructures such as IT.
Simply put, an agile enterprise is an enterprise that can do all of the above, preferably before any competitor does it.

I am a firm believer in that efficient communications and collaboration are the most critical success factors for basically any kind of endeavour, be it a project or enterprise. Any other factors can be important or even critical, but not as critical as these two. My simple conclusion about Enterprise 2.0 technologies is that if they can help to improve communications and collaboration in an enterprise, then they should be natural components in any initiative to make an enterprise more agile. As I have argued before in a post about agility and efficiency, BPM and SOA are two popular approaches that very much aim to make processes and IT systems more responsive to changes in the business environment. In other words, they both contribute to make the enterprise more agile. And this is in a sense what Enterprise 2.0 should be about - to help keeping the enterprise together while being in a state of constant change and making it move fast forward ahead of competition.

However, the need for increased agility is only one side of the story because most enterprises today are subject to an immense pressure from two sides - they need to become more agile and more efficient at the same time in order to stay ahead of competitors, or even just to survive as an enterprise.

My own analysis of why (Swedish) global corporations such as IKEA and H&M are so successful is that they have since long realized the need to be agile yet efficient and made it to the heart of their business. I personally like IKEA's business mantra "quick, lean and simple" and have adopted it as my own mantra. My interpretation of it is that "quick" stands for agility, "lean" for efficiency and that "simple" is what it takes to be both agile and efficient. Whenever there is a decision to be made, decision makers hear the mantra in the back of their heads and ask themselves three simple questions: Does this make us quicker? Does it make us leaner? And is it simple? If is not, let's try something else.

Sunday, July 8, 2007

Bertrand Duperrin Hits The Head On The Nail About Enterprise 2.0 - Twice

12:28:00 PM Posted by Oscar Berg , , No comments
Betrand Duperrin twice hits the head on the nail when commenting the ongoing (fruitless) debate on Enterprise 2.0 between Davenport and McAfee:

"I don’t really see in what asking whether 2.0 tools are an evolution or a revolution is relevant. The fact is there are tools and demands to use them in a professional context. Saying similar tools already existed and didn’t change a thing is neglecting what really matters : there is now a demand for new organizational practices that didn’t exist before, for the simple reason that business has changed, production has changed, immaterial is exceeding material, people have different needs to achieve their work, the way people use computers in their private sphere radically changed too, building a new emerging culture....//...The question is not about tools, it’s about the demand tools meet."

"...Another point is they talked a lot about tools, a little about people..and not about the enterprise by itself. That’s neglecting what I think is central : enterprise 2.0 is to make people more efficient to do their daily job that’s to say to achieve enterprise’s driven goals in an organizational pattern defined by the enterprise itself."

Now, let's leave this debate and focus on how to achieve results in an enterprise context by adopting and implementating (Web 2.0) Enterprise 2.0 technologies.

Thursday, July 5, 2007

The Curse of Jumping to Solutions

8:40:00 AM Posted by Oscar Berg No comments
A few days ago I received a document in my inbox from a potential customer. The document contained background information about a new internet site that should serve as a tool for distributing information and providing access to a "knowledge bank" for a network of organizations. So far so good.

When I started to read the document I realized that it was more or less a long feature list. It also hit me that there was no "social networking thinking" behind the suggested features. I would have expected this for a site that should support an otherwise loosely coupled network of organizations (well, people). To me, features such as "Expert database", "Newsletters" and "Project database" seem almost like relics of a prehistoric era.

Furthermore and more importantly, none of the features were traceable to any clearly defined objectives or target group needs. The features were motivated with sentences such as "We need this feature so that we can publish XXX" or "We have this database with XXX and want to extend it with this information". The list of features seemed to be a product of a workshop that started right away with brainstorming on features.

Well, how do you continue from there with that as your baseline of requirements? I would say that you should make the customer scrap the document and start all over again by identifying the objectives, the target groups and their needs, and THEN take a look at what features that can help to achieve the objectives and satisfy the needs of the target groups. But, I know how hard it is to make stakeholders who have already fought hard for their ideas and got them approved by others to abandon them. This is the curse of jumping to solutions. It happens ever so often.

Wednesday, July 4, 2007

Looking At Content Quality From Different Perspectives

8:17:00 AM Posted by Oscar Berg No comments
"One of the most obvious, yet surprisingly overlooked, components of a search strategy is the creation of quality content...//... The key question, however, is what is "content?" And what are the characteristics of good content?" (Search Engine Watch)

What exactly is content quality? There is much talk about high quality content, but very few dare, care or know how to define what they mean with it. Or, when talking about high quality web content, they point to what search engines define as high quality content, which does not at all need to be perceived as high quality content by your intended users.

I wrote a post some time ago about measuring the quality of a content product and pointed to three main content quality attributes – accuracy, timeliness and completeness. I put relevance as a forth quality attribute since I discussed content quality from a producer perspective. However, from a user (as apposed to producer) perspective, relevancy must be said to be the most important quality attribute of all. There are plenty of additional attributes to consider if I am to cover all dimensions of content quality, but it is fairly logical that - for a user- the content must:

1. be useful for the user’s objective or task (e.g. relevant)
2. be available when the user needs it (e.g. timely)
3. include all that the user needs to know, no more no less (e.g. complete)
4. come from a source that make you trust that it is true (trustworthy)

Content that is not perceived as relevant by the user is practically useless for the user. From a content producer perspective, content relevancy means knowing exactly what the user wants, something which is very hard to figure out. Even if you are both the producer and the user of the content, it is hard to know what will be relevant to you simply because your objective and usage context (the usage scenario) might differ from time to time. Given that it is practically impossible for a content producer to know what each and every user will consider as relevant in each and every usage scenario, it is more usable to talk about typical users, or roles, and typical usage scenarios. I recently read a nice post by Aurora Brown called “Redefining Quality Content For The Web” where she exemplifies how the perception of content quality changes with what perspective you perceive it from.

From a user's perspective, quality (or my preferred term, valuable) content, whatever the medium, is characterized by one essential factor: it fulfils the user's needs at the time they're looking for.”

From a search engine's perspective, quality content seems to be determined by the most on-topic (relevant) and trusted material in the online community. Relevancy is affected by the number of links to a page's content (like 'votes' for the page), the content's significance, how well the search engine algorithm understands the meaning of the page (semantics) and how well the content matches the searcher's topic. Trust is the other part of the equation, and is determined by the types of sites that link to a webpage.”

"From a web owner's, web masters, or website owner's perspective, quality content is simply content that garners links, offers value to users, is properly optimized and draws traffic that can be used for brand recognition or monetization.”

The point to make here is that content producers need to focus on defining (and measuring) what content quality really is so that they can ensure that the content they provide to their intended users is perceived as high quality content, and that this requires considering many different perspectives when doing so.

Monday, July 2, 2007

Defining The Knowledge Worker

2:28:00 PM Posted by Oscar Berg No comments
The classic definition of "knowledge worker" can be found in Wikipedia:

"Knowledge worker, a term coined by Peter Drucker in 1959, is one who works primarily with information or one who develops and uses knowledge in the workplace"

Here are some characteristics of a knowledge worker that I would like to add to that definition:

1. Your work and spare time is not defined by office hours

Your brain is not turned on at 8 .00 AM and turned off at 17.00 PM. If it was, you would not be able to do your job as a knowledge worker. A problem solving process continues in the back of your mind until it is completed and the problem is solved (or you have to finally leave it unsolved). Cognitive processes in your brain are constantly receiving input, interpreting it into information that you transform to knowledge when you apply it. You constantly prepare yourself and progress towards your goals by digesting information and planning your next actions. When you step out of the shower you might know exactly how things relate or how to attack a problem that you are working with. You write it down, let it go and continue with breakfast.

2. Your results and contributions are more important than face time at the office

If you have no tasks or meetings immediately at hand during office hours, you take a break to home to be with your kids, enjoy a walk in the park, meet with a friend or work out at the gym. You take the time off to let things fall into place as your cognitive processes are still being executed in the back of your mind. You don't just sit off your time in front of the computer when your mind is full enough of other things to digest. You know that you sometimes need to change environment to avoid cognitive deadlock. You know that it is your results and contributions that matter to your employer or customer and you have the mindset to deliver what you are expected to deliver. You have confidence enough to prioritize results before face time.

3. Your availability is more important your being physically present during office hours

You sometimes meet with colleagues and customers outside of the office in a more relaxed and creative environment. And you check things with colleagues during any time of the day. You know that a customer or colleague might call you, chat with you or send you an e-mail after office hours and you are mentally prepared to react when needed. It doesn't bother you since things are often not urgent after office hours and you probably can find a time slot sooner or later to react on them, and it usually has to do with simple status checking that does not require a lot of your time. And you utilize the kind of communication channel that is most convenient and suited for the situation you are currently in. Then you let it go from your mind and continue with whatever you were doing.

cartoon from www.weblogcartoons.com

Cartoon by Dave Walker. Find more cartoons you can freely re-use on your blog at We Blog Cartoons.

Sunday, July 1, 2007

The Shadow IT Department Drives Enterprise 2.0 Adoption

Some organizations understand the impact of the new Web 2.0 technologies in an enterprise context (Enterprise 2.0) and try to exploit them to their full potential. Other organizations might realize the potential benefits of these new technologies, but choose not to embrace them since they do not want to deal with the challenges they present to them in terms of security, compliance, etc. And then there are organizations that simply choose to see these new technologies as a nuisance, something which their employees should not deal with during working hours. But even when facing resistance for their management, employees who have already made instant messaging, social software, tagging, blogs and wikis to a part of their (work) life will find their way around to use these technologies. There is no way an IT department can stop (only hinder) them from using tools and technologies that they consider valuable.

Ben Worthen argues in an article in CIO that "the consumer technology universe has evolved to a point where it is, in essence, a fully functioning, alternative IT department." He calls it the Shadow IT department, "a natural product of the disconnect that has always existed between those who provide IT and those who use it...//...The era in which IT comes only from your IT department is over…//…Today, in effect, users can choose their technology provider. Your company’s employees may turn to you first, but an employee who’s given a tool by the corporate IT department that doesn’t meets his needs will find one that does on the Internet or at his neighborhood Best Buy…//…”There’s a simple golden rule,” says David Smith, a vice president and research fellow at Gartner. “Never use security and compliance as an excuse for not doing the right thing. Never use these as sticks or excuses for controlling things. When you find that people have broken rules, the best thing to do is try to figure out why and to learn from it.”

In an article in ITNews.com.au by J. Nicholas about the good and bad of web 2.0 tools, looks at the same phenomenon from a slightly different perspective:

“Even as Microsoft and IBM keep expanding their Web 2.0-style collaboration capabilities--with social networking tools like Lotus' Connections and Microsoft SharePoint Server 2007's support for blogs, wikis, and calendar sharing--many companies are concluding that one platform won't be enough…//…"If I do everything in Microsoft, what does that do to your modularity, to flexibility?" says Schueller, whose title is innovation manager in P&G's Global Business Services. "I wouldn't generalize that just to Microsoft. It's all the big vendors." IT also needs to learn how to incorporate tools employees bring in themselves, he says”

Diann Daniel asks if the enterprise is afraid of web 2.0 because these technologies are brought in from “the consumer space”:

“Web 2.0 can be especially challenging for CIOs and IT executives since its growth represents what some may consider "shadow IT." "Web 2.0 is a revolution," says Stowe Boyd, a consultant on social technologies and business and a senior consultant with Cutter Consortium. "It challenges a lot of base assumptions people have about how to operate in the world." Or how the world is supposed to operate. Unlike what IT executives are used to, "Web 2.0 technologies are coming in from the consumer space, and it's an interesting reversal," says John Hagel, longtime Web 2.0 consultant and chairman of an upcoming Deloitte research center on Web 2.0 and other technologies…//…Web 2.0 challenges the core assumptions about information in the corporation—who gets it, who owns it, and who has power because they have it. And that's a really scary thing for people used to controlling it. "Part of the job of a CIO is to create policies that prevent artificial pockets of power based on secrets and individuals exploiting power and not sharing it," says JP Rangaswami CIO of Global Services at British Telecom, a passionate supporter of Web 2.0 and open source. "Personally I want to see those pockets of power destroyed." “

Here are some (typical) voices about the void that so often exists between users and the IT department:

“I remember that when I used to work at Orange, many of my most useful tools were things I “wasn’t allowed” to have on my computer. I also remember that when I got really bad RSI and using dictation software was the only way to get me back to work, the IT department flat-out refused our request for Dragon. (Somebody actually said that if I couldn’t type anymore, they should just get rid of me.) My boss had to have a chat with somebody else’s boss to finally have the program installed on my computer” (Stephanie Booth)

“I’m not about to reveal what we do at MPOW, but if I went back to high lock-down on our PCs, I’d probably go completely mad. Our high-lockdown doesn’t even allow right mouse-clicks in the windows environment!!” (Gillian)

It is clear that in many organizations, the adoption of Enterprise 2.0 technologies is in fact driven by "the shadow IT department". To close the divide between the IT department and shadow IT department (the users), IT management must pay more attention to and listen to the users in the enterprise, realizing that the users often are one or two steps ahead of the IT department and already have evaluated and adopted tools and technologies that the IT department might now be considering.

The top-down approach that is commonly used when the objective is to support critical business processes with IT infrastructure and business applications must be complemented by a bottom-up approach, especially when it comes to communication, collaboration and productivity tools and technologies. The bottom-up approach is much more relying on the IT management getting aware of individual needs and initiatives and to encourage experimentation on grass-root level than on building big business cases for the management. But regardless of which approach is taken, the IT management must always make sure that it listens to the users in the enterprise to collect their ideas and experiences on how IT can support them in their daily work.