Information is like water - essential to our survival

Being able to communicate is absolutely essential for humans. As social beings, communication is a key part of our lives and what enables us to create and participate in various social structures. As humans, we need to belong to and participate in social groups or communities, from families to nations.

Communication is essential for any kind of collaboration (process two or more people work together toward a common goal). An enterprise can be defined as “…people getting together and collaborating to achieve a common goal” and communication is therefore vital for any enterprise to succeed. Although humans typically communicate and collaborate most effectively when we meet face-to-face in small groups, this is not practical in many situations. We often need to collaborate with people located elsewhere and sometimes we also need to communicate over time. We might also need to communicate with more people than is possible to communicate with face-to-face in a physical meeting. To enable collaboration in these cases, we create messages which we encode into various types of digital content (text, images, video, sound) and make accessible to the intended users via information technologies. In a sense, information could be compared to water:

• Information, like water, is essential to our survival. Given that collaboration is what an enterprise is about, information is also essential for the survival of enterprises.
• Information, like water, needs to be managed so that it is supplied to the enterprise users when and where they need it.
• Information, like water, needs to be of sufficient quality to be suited for its intended uses.
• Information, like water, is managed in a system which collects it from various sources and distributes it to the users.

The analogy with water can also be used to illustrate the purpose of different disciplines dealing with information within enterprises:

• EIM (Enterprise Information Management) is about ensuring that the users will get access to the information (water) whenever or wherever they need it. EIM is about ensuring that the information (water) is consistent, that is it is of sufficient quality and that it will be delivered (flow) to the users in a timely manner.
• MDM (Master Data Management) integrate information (water) from various sources, store it in a repository (reservoir), cleanses (purifies) the information so that it is of sufficient quality, and makes it accessible to any application (water supply system) that needs it.
• SOA is an architectural style that defines how applications (water supply systems) should architected for ensuring interconnectivity, modularity and reuse of key software capabilities (pipes etc).
• Enterprise Architecture (EA) is usually performed by an EA team (city planning department) which besides organizing the business and IT resources so they align with the business strategy also creates the principles, rules and guidelines for how the information (water) should flow throughout the organization (city).

A trail of posts on SOA and organization

I followed a trail of posts about SOA and organization and found some nice stuff along the way, starting from "Tearing down silos, brick by brick" by Joe McKendrick...

"I once heard a rumor that there actually is a company with two integration teams that actually meet and talk once or twice a year. Just a rumor, mind you."

"Lorraine Lawson brought up the whole issue of silos and lack of communication in a recent post, and the implications for SOA. Namely, that SOA not only requires developers to know what other developers are doing, but that the business know what developers are doing, and visa-versa. Lorraine cites the example of one IT professional who had no idea what his coworkers did all day."

"I’ve also heard it said that competency centers also lift SOA matters above the grind of organizational politics. SOA projects can be prioritized according to the needs of the business at large, and not to serve the agenda of one business unit. Essentially, they can be silo-agnostic. (How’s that for a new term?)"

...then to the post by Lorrain Lawson "Overcoming IT Siloes on the Road to SOA Success":

"I’m hoping and, frankly, assuming, that most organizations aren’t quite that dysfunctional. Still, even if your developers are 25 percent more talkative and social than the ones in my friend’s workplace, you can see how organizational issues within IT could be a big barrier for successful service-oriented architecture."

"SOA requires developers to know what other developers are doing – hence, you have repositories and registries. But even with these technology solutions, how the IT organization interacts internally and with the business is a common problem for SOA implementations, says Eric Roch"

...and then back to the post "Organizing for SOA Success" Eric Roch:

"While most IT organizations are focused on the technology aspects of SOA a common barrier to SOA success is IT organization itself and how the organization interacts internally and with the business. IT organizational change is needed for SOA governance including the adoption of a SOA software development lifecycle and the runtime governance of shared services and the components that support them"

"The best practice for SOA organization is to establish a Competency Center to own the services catalog, common schemas and governance processes. But a SOA Competency Center does not just spring up overnight, nor will it address cross-functional barriers without participation from other IT entities."

"To overcome organizational barriers I recommend forming a cross-functional SOA Steering Committee composed of the leader of the enterprise SOA initiative, a lead architect from each functional-application system and an enterprise architect"

...and then finally back to a video clip of a customer (Luxottica) who according to Eric Roch is "linking their success to the SOA organizational structure and roadmap". It is worth checking out. To quote one of the persons appearing in the video, Ken Faw who is Director of Integration Strategies at Perficient:

"We don't have to have a massive governance effort. We have to get it to fit in into the whole evolution of people's intuition, their capacity to absorb it. To me, service-oriented architecture is bigger than the entry point - its the plane, it's the whole transformation of intuition that is going to happen to people, that helps them to become more autonomous agents, working in parallel to achieve multiple business objectives."

Yes folks, there we have the mysterious main ingredient in the recipe of success again: PEOPLE. The main ingredient is not technology, nor is it the organization in itself. It is the people, how they think and behave. And the problem with people is that if you can't do it with them, you can't do it without them either. Wouldn't it be easier if it was all just a technology thing, about bits and bytes?

This week in links - week 6, 2008

Matthew Hodgson writes about the need for more granularity in user roles in order to make the right decisions on what kinds of functional requirements that will meet user needs:

"Do you allow people to comment, review, rate and ask questions on your website’s articles? If you do, you’ll be enjoying the fact that your own users are helping others know what information is valuable on your website. It’s also valuable feedback because it helps you improve the quality of your information. Over the last month, I’ve been working on a strategy for a client to help them introduce this sort of user-to-user and business-to-user interaction. My client though, has until recently, thought of their users in the same way they do their print magazine. This has meant that their market segmentation is broken down into 3 (non-mutually exclusive) roles:

1. those that use the website,
2. those who read the magazine, and
3. those who buy stuff.

Unfortunately, this is not enough granularity to make informed decisions on the functional requirements that are necessary to meet user’s needs. By using the taxonomy of social computing, the market segmentation, and user needs, become much clearer."

Kyle Gabhart argues that EA, SOA, BPM and so forth are all different labels on initiatives trying to address the same kinds of problems in enterprises, such as:

• "Business and IT need tighter alignment
• Visibility between business and IT should be increased
• Governance is needed at various levels of the organization to reduce risk
  and protect ROI
• Business processes and technology solutions should be more flexible and better able to adapt to changing demands
• Business processes and technology solutions should be designed intentionally and with sufficient rigor

The labels attached to these trends vary from enterprise to enterprise. Some drive toward one or more of these goals under the EA umbrella, others under the BPM label, and still others are talking about SOA. Some organizations use two or even all three labels. Regardless of the attached label, it is a strategic initiative at the business unit or enterprise level that aims to improve business predictability and squeeze more value out of technology investments."

Stewart Mader lists 7 strategies from the Society for Information Management's Advanced Practices Council for implementing a successful corporate wiki, the last one being the most important according to me:

"7. Understand wikis are best used in work cultures that encourage collaboration. Without an appropriate fit with the workplace culture, wiki technology will be of limited value in sharing knowledge, ideas and practices. (90-9-1 Theory)"

Everybody wants an enterprise-wide information model - so where is it?

Every project that aims to improve how information is used and managed within an enterprise (be it related to ECM, BI, SOA, or whatever) needs to do the following:

1. Ensure that key concepts have the same meaning and are represented by the same terms everywhere they exist and are to be used. This is to avoid basic misunderstandings that might put the project in the wrong direction.
2. Ensure that the information resources that are to be used and/or managed are identified, defined and values (so that key assets can be identified), that their relationships to each other are known, and that every instance of these information resources has the same - or at least a similar - structure and attributes. This is to be able to focus the improvements where they give something back (ROI) and to simplify integration and exchange of information resources between people, activities and applications.

After having realized that there are no updated conceptual and logical information models readily available, most projects start to develop their own. Thet start developing their models from their own perspective, covering only their areas of interests. And if they succeed in developing such models and making them usable for the purpose of their specific projects, they soon falls into after the projects have ended.

Now, imagine if the project would have access to an information model describing all information and content resources - structured as well as unstructured - that exist within the enterprise. First of all, it would mean that each project would not need to spend energy, time and resources on developing their own model. Each project would be able to make a jump-start and focus on identifying areas improvements and developing efficient solutions instead of being occupied with trying to describe how the world looks like. And even if they would still look at the world from their own specific view points, they would be starting from the same foundation as every other initiative. They would speak the same language and see the world in a similar way as other initiatives taking place elsewhere in the enterprise, and it would be less likely that they would misunderstand each other.

An enterprise-wide information model is the dream of most Information Architects. The challenge is to develop an information model describing how all information resources within the entire enterprise are related instead of only doing it for a specific domain or application. The information model could then be made available to all initiatives within the enterprise, as a shared service.

Since developing and maintaining an enterprise-wide information model must be a never-ending task and requires a holistic approach and lifecycle perspective on all information and content resources, it cannot be accomplished by a project. The only reasonable approach would be to set up a team that is dedicated to define and maintain representations of the enterprise information architecture. This team would also be assigned the responsibility to continuously refine and assure the quality of the information and content resources and the relationships they have to each other (the architecture). The team must consist of skilled information analysts, information architects and information stewards. However, to be successful the team must be operating throughout the enterprise, helping out different initiatives. Otherwise it will end up doing like most enterprise-wide initiatives – developing something that is neither usable nor based on an understanding of how things really are in the different corners of enterprise.

When to SOA or not to SOA is no longer a question

The concept of SOA has been along for a long time and originates from the IT side as a way to architect and design information systems. Recent years of initiatives to extend the enterprise information systems beyond firewalls out on the Internet and the need to expose and access functionality and content in legacy systems have made SOA to the dominating approach to IS architecture. Enterprises have come to realize that SOA is a necessity if their IT-based information systems are to be able to stretch out on the Internet – but also to quickly respond to rapid business changes.

Implementing SOA is however no guarantee that the IT systems will support the business as required by the business. Successful service orientation of a business and its information systems is tightly coupled to the ability to see the customers and respond to their needs. Regardless if the customer is internal or external to the enterprise, the customer is not interested in the service itself, but rather in the resources (informative content or other types of content) that it provides him with – and if and how they help him achieve his goals. Simply put, the customer does not consume the service itself; he consumes the outcome of the service.

Even thinking in terms of “services” might not be enough to be able to see and understand user needs. We must always remind ourselves that the services exist only to serve customer needs. Let’s take an example.

Physically handicapped people don’t have a need for wheel chairs. Their need is to move as freely and unhindered as possible despite their handicap. A wheel chair is a means helping them do that. But, there are other means too and someone will probably invent even better means than wheel chairs in the future. A product-oriented wheel chair manufacturer that does not understand the needs of their customers lacks the ability to innovate. When the innovation eventually comes, something that helps to satisfy the needs of their customers better than their wheel chairs, they would probably go on making their wheel chairs until they are either forced to change their business or put it down.

The point is that we must always define and design services in the light of real customer needs. That applies also for IS services in a service-oriented IS architecture. Otherwise, we might end up thinking that a service has its own reason for existence. That typically happens in engineering-minded businesses that develop products or services based on their own ideas rather than based on customer needs. They often end up asking themselves why their products aren’t as successful as they deserve to be and throw the hot potato over to the marketing department; “How can we convince the customer that he needs our product? “ In that stage, it is probably a little too late to tell the engineers to start all over and go to the customer to ask (or observe) him what he really needs.

How much "Enterprise" is there in ECM?

A lot I would argue. But ECM is - sadly - often discussed on a level where it is synonymous with ECM technologies. However, ECM is not a technology or a software product; it is a strategic approach on enterprise level on how to address the content management issues and challenges most enterprises are facing today. The disciplines of Enterprise Architecture and ECM should be a perfect match - in theory. In practice, their relationship is struggling because ECM is much more occupied with bits and zeros than with people and processes.

Here are a few posts more or less related to this subject that I have found interesting:


"Enterprise Architecture and Enterprise Content Management" by Rajiv Dewan:

"In my experience working in the ECM arena, I have seen numerous deployments where the client is focussed on a particular business problem, or maybe is trying to address a particular set of regulatory guidelines/requirements. What seems to be lacking is a true understanding of how a content management solution fits into the Enterprise Architecture ...//.,. My personal view is that most ECM deployments, and this is on the vendors and systems integration/consultants who deploy these solutions, are not really architected to fit into a corporations 'Enterprise Architecture'. Furthermore, the discipline and rigour of EA is not really followed as ECM solutions are developed"


"Enterprise Architecture: ECM and Compliance Oriented Architectures" by James McGovern

"ECM is not an insular domain and should participate in a larger context ...//... Documentum, Alfresco, Nuxeo, Stellent, Filenet, OpenText and others are way too insular and need to start thinking more about how folks outside the ECM domain may use their products."


"The Enterprise Content Management - SOA Divide" by Alan Pelz-Sharpe:

"In the content management world, I sense something of a backlash brewing against SOA (Service Oriented Architecture), but I wonder how real or or even practical this is. With most Fortune 2000 firms already way down the SOA path, there seems to be no turning back. At the enterprise architecture level, there is no Plan B. So the issue for me is not whether SOA is the way forward for ECM, but rather how seriously some of the ECM vendors are embracing it."


"Transparent ECM and SOA" by Laurence Hart:

"This is where my concerns surface. EMC’s Documentum message has been subtly changing. Less focus on application-like modules, more focus on toolsets, integration, methodologies, SOA concepts and the like. It hasn’t just shown in the marketing. Several of the Content Applications have been slow to evolve in the last few years. There have been improvements, but many of those coincided with the unification of the product stack ...//... Here is the Catch-22. We need an ECM platform that can easily be plugged into an Enterprise Architecture. On the other hand, we like having good, solid Content Applications from the same vendor. Oh, there are times we want/need to mix and match, but many organizations want to at least be able to consider the applications provided by the ECM vendor. It also shows an understanding of the problems that the ECM Platform needs to support."


Finally, James Melzer has developed an interesting diagram called "EIA in Context" which he introduces in the post "Enterprise Information Architecture in Context". He explains his view on the relationship between the Enterprise Information Architecture (EIA) and ECM. The EIA defines the structure for content management, but it must first be aligned with the Enterprise Architecture. To quote:

"ECM is a permanent ongoing process to control a never-ending stream of content - to file it, organize it, and deliver it to the people who need it. EIA is the intelligence behind content management. It translates user needs, business goals, policies, and standards into a coherent plan for content management."

The Value of Architecture

The value of Enterprise Architecture is zero, if you have an enterprise that exists in a complete static environment, without any need for improvement. The value of architecture is also minimal if the size of your business is small. If you have one customer, one product and one employee is it rather simple to adapt to changes in your environment. With more customers, more products and larger organisation, changes to your organisation are more complex.

First of all, Enterprise Architecture is a vehicle for risk mitigation. Projects fail, and the larger the project, the less the chance that it succeeds. Large programs are even worse. Why is it so?

Standish Group make annual surveys of project results and their findings are not very impressive. Worst of all, there have been no major improvements during the last twenty years. If we look at the reason behind failures, we can identify two major factors behind the figures that count for nearly 90% of the reasons. They are the solution as such and how the project is carried out. Lack of proper project and program management does count for approximately 50% of the failures. The next 40% of failures are due to the lack of architecture. Finally 10% are classified as others, i.e. Murphy.

The other finding is that small projects have a near fifty per-cent risk to fail. Large program does only succeed in 2% of the cases if we look at the statistics. Larger program add complexity due to mutual dependencies between projects. The dependencies exist both between different applications and between processes and people. More applications and larger organisation add complexity to the transformation. Not to forget the strong relationship between the organisation, processes, information and applications. If we don’t handle this relationship will we have a huge gap between business units and IT organisation.

Enterprise architecture is how to describe the situation today, how it will look tomorrow and how we will get there in a controlled way.

If we have a more positive attitude, Enterprise Architecture helps the organisation to improve how they work and add value to their customers. Improved processes and IT-systems that simplify manual work need a strong foundation.

Enabling new business, as information, communication or entertainment services, to the enterprise has a big impact on requirements on the solutions, thus also on the architecture. Collaboration with external parties is another example that call for flexible solutions.

You will have a strong business case for Enterprise Architecture if your organisation stands before a major transformation, due to changes in the environment where the organisation act.

A last word, in a perfect world Enterprise Architecture would be the silver bullet. But in reality, we must handle a number of shortcomings. These are to be described in the next articles.

EA Soft Power Project Reviews (coach, don’t kill)

Enterprise Architecture made practical seems to be a topic that currently attracts a lot of attention. In a former post I tried to summarize some guidelines on how to approach Enterprise Architecture (see Practical Enterprise Architecture ). The key purpose of the post was to argue for a more agile approach that is better adapted to the stakeholders' needs and capabilities.

In this post I will describe some tactics concerning Enterprise Architecture and project reviews. Why bother reviewing projects from an Enterprise Architecture perspective? Below are a few possible reasons:

• A review may result in a more balanced basis for project decisions
• A review may clarify the alignment between business goals and supporting IT
• A review may identify synergies and explain different solution alternatives
• A review may engage competence that the project might have disregarded
• A review may discover risks that require mitigation
• A review may reveal aspects of the solution that are not obvious for the project members, e.g. re-use, integration and security

A review can be executed in different ways depending on the size and complexity of the project at hand. Generally, project reviews are performed in a very formal style, when the project is well under way, and the Enterprise Architect or EA team often takes the role of a (bad-guy) police. But is this always necessary?

An alternative approach might be to think about the review as a learning experience for the participants where the Enterprise Architect takes the role of a coach. The style of the review is preferably less formal. The Enterprise Architect identifies issues, leads a constructive dialogue and supports the project by suggesting different architectural improvements. These improvements are for the project to address and resolve.

This type of soft power project reviews should preferably start in the early project phases. This ensures that the project is doing the reasonable right things in the reasonably right way to minimize project risks as early as possible and to avoid the high costs of late project changes.

So, what kind of questions might the Enterprise Architect or EA team use as a foundation for a constructive dialogue with project representatives during an initial project phase? Below are some examples of statements that might elucidate many common project and architecture issues:

1. The suggested solution is documented and outlined in a comprehensible and concise way
2. The suggested solution is linked to significant and measurable business drivers, scenarios and services
3. The suggested solution clearly presents relationships to internal and external actors and stakeholders
4. The suggested solution illustrates key services and components as well as vital interfaces and interactions
5. The suggested solution answers to critical non-functional requirements and service levels
6. The suggested solution is compared to different solution alternatives and emerging IT trends
7. The suggested solution is related to its life cycle and to possible changes of the users and their usage
8. The suggested solution shows dependencies to existing IT plans and project portfolios
9. The suggested solution adheres to enterprise strategies for IT competence and sourcing
10. The suggested solution follows the established principles for Enterprise Architecture

The above statements may seem simple, but my experience is that most IT projects can not answer to all of them. A project does not need to have detailed responses to the statements during an initial phase. The point is to make sure the project members have started to think about them. Detailed explanations of how the project will solve them will then come naturally during forthcoming phases and reviews.

What is Enterprise Architecture?

If you ask five persons, “What is Enterprise Architecture”, will you probably get five different answers depending on their background. My answer is that Enterprise Architecture is a way to support changes of Enterprises.

If you instead ask them, “What is architecture”, will they come up with similar answers. Architecture is for most of us are synonymous with the Opera house in Sydney, Petronas Towers in Kuala Lumpur or La Sagrada Familia in Barcelona. It could also be our office where we work or our home where we spend a large part of our lives. The term architecture is for all of us tightly coupled with buildings or cities.

The fact that successful architecture needs a proper design and thoughts before starting the construction may not be aware to us before we try to renovate our own house. Architecture is the art of matching requirements with constraints in complex situations.

This is why the description of Enterprise Architecture should be to design an Enterprise so it can produce and deliver products and services to their customers. But an Enterprise is seldom built from scratch. It is more like an old house that have be build out during different time periods to fulfil the different needs of the owner. This is why the title for series of articles is The Changing Enterprise. Without changes in the surrounding environment, there is no need for major changes within the Enterprise.

One the other hand, without Enterprise Architecture an enterprise will probably fail if a major change in conditions occur. It will meet the same fate as the dinosaurs.

Enterprise Architecture is first of all a way of controlling change in a predictable manner and migrating risk. Second, it is also about creating support for more efficient ways of working and improving operational efficiency. Third and last, it is an enabler for new business opportunities with the help of Information and Communication Technology.

In order to achieve this in large complex organization, Enterprise Architecture has to handle questions about organization, processes, information management, applications and technical infrastructure.

EA is therefore not a technical issue for the technology department, but instead an important question for the CEO.

The Changing Enterprise - Preface

The main reason for Enterprise Architecture is the Changing Enterprise. The environment the Enterprise exists in evolves and puts new demands on the existing organisation. Enterprise Architecture is about mastering changes in a predictable manner.

This series of articles will give an introduction to Enterprise Architecture towards stakeholders inside and outside the organisation. They will cover a number of topics in a straightforward way to give the readers an understanding of the challenges with change.

Preface
1. What is Enterprise Architecture?
2. The value of architecture
3. How well do we perform?
4. What is good enough?
5. Remember the customer
6. What do we need?
7. EA governance model
8. EA process
9. EA framework
10. EA tools
11. Abstractions levels
12. Iterations
13. Prerequsite for Enterprise Architecture
14. Conclusions
References
Biography

Welcome to share my thoughts.

Casimir Artmann

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.

Some Comments on Team Collaboration and Project Management

Project management is about getting the right people to collaborate as efficiently as possible in order to achieve a common goal - on budget, in time and in line with (or, if possible, above) expectations.

It surprises me how many organizations seem to believe that project management is first and foremost about making budgets and time plans and how little effort they actually spend on creating a sound collaborative environment for their projects, even when they are using remote (virtual) teams. Project managers should not be seated in front of their laptops to create time plans and budgets with a project management bible in their lap. Instead, they should try to create an environment for their projects that fosters efficient communication and collaboration. With that in place, they can focus on defining and clarifying the goals and main deliverables of the project, finding the right people and making them connect and get to know each other. After having defined what the project is to achieve and what resources are available to it, the project manager should use the time constraints and budget to shape and trim the project.

As a project manager, it is essential to try to understand what is needed for achieving efficient collaboration within the team and with project stakeholders. James Dellow points to the following collaboration challenges for remote teams in a post about Collaboration challenges and success factors:

• "Willingness to collaborate (driver by a combination of necessity and opportunity);
• That all the people involved have the right collaboration skills; and
• Having access to and selecting the right information and communication technologies (ICT)."

He then presents the following critical success factors for creating a sustainable virtual team:

• "Control - does the team have a clear sense of direction and progress towards their objective;
• Enabling Resources - this includes providing people with time to collaborate, funding for travel when required, people to provide support and also the right work environment and facilities, etc; and
• Communications - extra effort is required to supplement the social capital that is created naturally in a co-located team through a combination of formal and informal communication."

He continues with making this important point:

"Underlying these challenges and critical success factors was the point that all these issues that can be managed, but often required forward planning (through a start-up or refresh process for existing remote teams)."

It is clear to me that a lot can be done to create an environment that can foster efficient communication and collaboration for projects, and that providing access to the right collaboration technologies is a big part of that work. In a post about team-based project management, David Coleman gives this simple and powerful example of how the proper use of collaboration tools can shorten the project execution time:

"Imagine you’re a contributor on a project and you are in the project space looking at a document and you have a question for one of the authors of the document. Today, the mechanism to deal with this is e-mail. You have to flag the document. Possibly highlight the area in question, and then e-mail your question to the author(s) in question, a process that could take days!

Now imagine the same scenario, but you had IM and Presence Detection integrated into the project software. You could see that one of the author’s is on Yahoo Messenger, you can ping them, ask your question, make the change to the document, and be done in a matter of minutes instead of days .

This is where RTC (real-time collaboration) tools really shine, in facilitating the interactions between those in a project, not cutting the task time down (although that may occur also). If you look at how the work really gets done on a project, it is the time in between the task work that really kills your schedule. If some of that inactive time can be made productive and cut way down, then the whole project will move faster."

Organizations that execute a lot of projects with remote teams should not hesitate to embrace Enterprise 2.0 technologies such as wikis, blogs and real-time communications and find out where and how these can contribute to a more efficient environment for communication and collaboration.

Making the Complex Clear

As an IT professional I see it as one of my main tasks to make complexities clear to business people and other stakeholders that are making or influencing decisions about IT in an enterprise. With this I mean primarily two things:

1. Making complexities easier to understand
2. Revealing unnecessary complexities

After this has been done, it is easier both to reduce and manage complexities, as well as establishing the proper IT/IS strategies, improving processes and making the right choices on IT investments.

However, it is important to understand that complexity does not need to be a bad thing, it just needs to be at the right place. In fact, increasing complexity is required for making a business more agile as well as increasing cost efficiency by enabling reuse and faster modification of IT solutions. Besides having complexity at the right place, there needs to be predictable patterns behind it, and it needs to be based on explicit and well established principles and rules.

The increase of unnecessary complexity is definately a maturity thing. By applying a coherent architectural strategy, using design patterns, enforcing standards, establishing and exchanging best practices, and consolidating heterogonous environments unnecessary complexities will be reduced. It is my strong recommendation to anyone dealing with IT to make Einstein's "Make everything as simple as possible, but not simpler" to their mantra. Because in the IT industry we tend to overcomplicate things, add unnecessary complexity, and not care enough about following principles, patterns, standards and guidelines.

To make necessary as well as unnecessary complexities clear to business decision makers is a challenging task for IT and management professionals. But there simply is no escape for businesses - making the complex clear is an absolute necessity for making the right business decisions.

Business Agility and Efficiency make the Business Case for BPM and SOA

To meet the challenges of a fast-paced global business environment, an enterprise must be able to change rapidly. And to be able to do this, it has to become more agile. On the other hand, the enterprise also needs to become more efficient so that it can respond to the pressure from competition and shrinking margins in a global economy. This very simplistic illustration is meant to illustrate how the gaps between the business environment, the business processes and the IT systems are increasing over time in many enterprises due to the inability to quickly respond to external and external changes.



Becoming agile means that the enterprise must be able to keep itself together and avoid any gaps between the business environment, the business processes and the IT systems. Efficiency, on the other hand, is about streamlining, automating and optimizing processes and removing redundant processes. Efficiency is also about becoming better at reusing IT investments and making sure that when the business is trying to respond to changes, the IT systems can easily, and at reasonable cost, be adapted to support those changes instead of becoming obstacles.



Enterprise Architecture (EA) is a practice of describing the current and desired state of processes, rules, resources, roles, organizational units and information systems within an enterprise, with the overall goal to align them all with the objectives and strategies of the enterprise. Common requirements that modern enterprise architectures are supposed to handle and support are increased agility and efficiency. This also explains why BPM and SOA has become so widely adopted by enterprises:

• Business Process Management (BPM) is a field of knowledge combining management expertise with information technology capabilities that guides on how to model, design, implement, govern, measure and analyze operational business processes so that they align with business objectives and strategies, but also so that processes can be streamlined, automated, optimized for performance and/or removed if being redundant.
  
• Service Oriented Architecture (SOA) is an architecture for information systems that is based on the concept of service-orientation. This means that information is made available as a service for anyone to access without knowing the underlying implementation. An IS architecture with these qualities is well suited for aligning existing and new information systems with business processes, while at the same time being able to meet business demands for flexibility and cost reduction.

So, agility and efficiency is the two main drivers behind BPM and SOA. I hope this post provided some context to these abbreviations.