Stress-test Your Enterprise Architecture: The 7 Questions to Ask

Defining an Enterprise Architecture enabling IT to successfully capturing the business requirements is a daunting task. Have I captured the essence? Will architects and business analysts understand it? Is it pushing our business forward through improved alignment between business and technology? Those sorts of questions are always spinning around when defining an Enterprise Architecture. A recent article in HBR "Stress-test your strategy: the 7 questions to ask" inspired me to think of the 7 questions that would help stress-test an Enterprise Architecture. Here's my take on those questions. In coming posts I will dive into each of the questions to further add some meat.
What do you think are the relevant questions to ask stress-testing en enterprise architecture?

Here's my 7 questions stress-testing your Enterprise Architecture:

1. What is the driving purpose behind the business?
• The enterprise architecture is there only to support the business purpose, right? Making sure that the architecture supports, enables and drives business is make-or-break. The reminding 6 questions assumes that the right business purpose is in the bulls-eye.
2. Which critical effect are you aiming for?
• Be extremely sharp on the effect that the architecture should deliver in its own right. It's easy to do a lot of everything and nothing of what is important. Measure and visually communicate current state and progress. Avoid finding yourself in a state of active inertia.
3. What is the key customer value proposition that is supported?
• Your customers turn to you because they perceive a very specific value offered. Align your architecture to support that value. Never find yourself in a situation where the architecture is considered state-of-the-art and the business struggling.
4. How is complexity being killed?
• Be very clear and upfront with how complexity is eradicated from both IT and business processes through the architecture. Scale back on fancy solutions. Simplify and design for evolution. 
5. Which collaboration is generating creative tension?
• Generating new ideas and improving execution requires extensive collaboration internally and with external stakeholders. Enabling and pushing collaboration through both tools and also more importantly through open access to the central business systems will spur further performance improvements.
6. How are the implementation boundaries defined?
• Central to any architecture implementation is how it is sequenced, domains affected, and what is not touched. Without clear boundaries scope creeps during implementation. There's always this domain or system over there that needs to be touched. Timing and risk will be severely affected if the boundaries are not well defined. What not to do is as important as what to do.
7. What architectural implementation uncertainties keep you awake at night?
• Your architecture is not better than its implementation. The success depends on the way it is implemented. To succeed you have to carefully monitor the uncertainties during implementation. Which parameters you choose to keep your eyes on has to be connected with question 1 and 2; business purpose and customer value proposition. Ensure that the implementation secures successful realization of those answers.

Designing and implementing a successful enterprise architecture requires making tough, sometimes hard choices. These questions will hopefully further refine your architecture making business success a fact. There's no magic bullet that can zero in on the pitfalls of your architecture - just hard work and diligent implementation. Only then can you be confident that your architecture is on track.

More to read:

• HBR November 2010: Stress-Test Your Strategy: The 7 Questions to Ask

Enabling knowledge sharing

Sharing knowledge among peers, colleagues, and partners enables new combinations of existing individual knowledge. How to decide when, how and to whom sharing should be performed?
Dividing stakeholders into two categories; key individuals and community; it becomes easier to separate when, how and to whom knowledge sharing should be done. Key individuals are the most important peers, colleagues and partners with whom you need to share knowledge. Community are the groups of people with whom knowledge sharing benefits both parties.
I will here outline some thoughts, guidelines and examples on using key individuals and community as means of identifying knowledge sharing requirements. As example we will use a global telecommunications company with a multi-site R&D organization with deep customer and external partner relations were to define which knowledge to be accessible to whom.

• Key individuals. Simplifies sharing efforts through being aware of the key persons enabling you to continually satisfy their needs. Identify who the key individuals are, their knowledge domains, when and how they need knowledge. Be very restrictive on whom to define as a key individual. It is advisable to have a discussion with each person to gather their personal expectations. Which knowledge, when do they need it, in which format and how to access it. 
• From the example: Identifying the key individuals among the different engineering organizations, customers and partners (in all 7 internal, 3 customers and 4 partners) opened up the opportunity to tailor communication and filtering the knowledge that was made available to each of them. Some wanted only working and verified knowledge, others wanted very early ideas. Among the engineering teams very open sharing is key to successfully build upon each others experiences. With partners knowledge regarding common projects that were patented to protect IP was shared. Through the individual attention paid to each one their interests can be met.
• Community. A broader set of people in each organization can be treated. These can be development teams,. business development, sales, support, etc. Their needs on knowledge are of course also specific, but through treating them as a community it is possible to still manage their needs. If not managing them as a community they will consume too much of your resources and benefits will not materialize. A community is a simple way of giving these organizations some special treatment without having to be personal.
• From the example: Within one engineering team in Spain they had developed a new communication and message container. The actual thoughts and technologies behind these were needed by the engineering team in China in their IPTV development. Through defining the Chinese team as a IPTV community (possible including others over time) they could easily define which knowledge was needed by IPTV and make it available to that community without thinking too much on who's on the other side. Following the agreed upon depth and timings enables the Spanish engineering team to control access and still keep efficiency.

Conclusion: Identify key individuals and communities of interested parties in the knowledge you produce and that will enable much simpler control and maintenance of knowledge sharing.

The forgotten screw - How to create culture of collaboration?

Language made man into what we are today. The ability to communicate between individuals and over distances can be seen as art-work and trade in human societies already 100.000 years ago. Jesus shared bread and fish among the gathered people and got back much more than he gave away. This illustrates that when you share and collaborate you get plentiful in return.
So how can we take language and the written word to the next step and become collaborators?

Research has shown that communication between people diminishes with distance and already 100 meters makes daily communication come to a halt. To foster collaboration in an ever more global world where interaction is not just done two floors up, but across oceans. Tools are important and necessary. Without the right mindset and culture it will be hard to make it work. Let's examine some principles to foster collaboration and knowledge sharing:

• Make it fun
• People are drawn to each other when they have fun. They share experiences, knowledge and build trust within the relationship. Ensure that there is a mix of old friends and newcomers to further increase the value of networking.
• Make it easy
• Remove hurdles and thresholds to collaboration.Can the tools be accessed on the run? Is the user interface simple and time saving? Can I find what I'm searching for? Is it free?
• Make it rewarding
• Make sure that competition, financial compensation etc are playing in the direction of collaboration. The collaborative culture and tools must give the most rewards, not the old way of working. Which resources and knowledge needs to be present to start collaborating from day 1?
• Make a change for change's sake
• Change the organization, responsibilities or products. Changing one piece at a time forces people to build new networks, collaborate with new people and generating new knowledge. All the time while old relations are kept.
• Make it measurable
• Measure the level of contribution. Rate people's contributions on how valuable others were finding them. Measure where connectivity and collaboration occurs. Are we missing something in between certain organizations or countries?

Have a sincere look at your collaboration environment. Are there screws forgotten here and there? Representing lost value and rework. Knowledge and experience not shared. Are the right departments working together? What about measurements?

Get started with creating a culture of collaboration and knowledge sharing!

More to read:

• MIT Sloan Magazine Fall 2010: The Collaborative Organization: How to Make Employee Networks Really Work
• Crowdsourcing by Jeff Howe

Seeing is believing - how visualizing the innovation portfolio makes better decisions

Running an innovation organization effectively requires close control of two disparate dimensions - the value of the portfolio (regardless of currency - $, time, IP ...) and how investments are made (regardless of currency - $, time, IP ...). Keeping an eye out for opportunities, spotting potential issues and making prioritizations between different projects requires a good visual representation that enables all stakeholders to grasp their share of interest.
What can then be said about how such a visualization tool materializes? Which decision types are helped through improved visualization?

• Set a goal of killing at least 10% of all projects each year. With an average running time of 2 years that means that 20% of all projects get killed. The number has to be adjusted for actual project duration. 
• Decide on which metrics to measure for killing decisions. Is it time ahead of competitors? Is it potential revenue? Is it time-to-market combined with potential value. Make that number visible and make sure it gets updated regularly. 
• Set a goal of only running 20% of your projects at any given set of time. If average number of projects is 2 years that means 10% running in parallel. Measure and visualize project duration, time-to-market ((time left * market value)/resources ($, people, etc) and alignment with current strategy.
• Define share of projects on different levels - extension, incremental or radical. Kill projects from each category to keep the balance and loose in the long run.

These are just a few examples of the importance of measuring and visualizing the performance of the innovation portfolio. Which are your favorite way of illustrating innovation portfolio status?