In my previous blog post I talked about how to Define Your Collaboration Strategy With Architecture and the importance of being able to visualize how technologies critical to your collaboration strategy will be implemented. Before that, I talked about how to Model "A Day in the Life..." for Better Collaboration and the importance of use cases for different types of employees as they go about their day to day activities. Now I'd like to talk about how to visualize collaboration use cases and the capabilities required using architecture.
As IT professionals we are obligated to understand the business requirements of the departments we support, but we don't always think that way. We tend to be technologists and think about the value of technology. We see value in how simple, flexible, or configurable an application is for the user. Many times the perspective of the user is our own and we may not take into consideration different skill sets and needs.
The best way to understand the needs and skills of the users you're supporting is to understand the day to day activities of those users. These are the use cases that need to be defined with support of different departments. Different departments will have different priorities. For example: Human Resources (HR) may prioritize efficiency and productivity, Sales may be focused on growth, while Product Management requires R&D and innovation. Regardless of departmental priorities, each department will be using the same collaborative technologies. As you work through the many use cases you'll discover overlapping capabilities that users will require.
The next question is how to instantiate the capabilities your users require. This is where architecture matters. You probably have several different architecture views of your enterprise capabilities that look something like the Cisco Collaboration Architecture. It's important to have the level of discovery that shows where you are today, as well as, the vision of how things should work over the next couple of years. This is your technology roadmap and you'll want to review it often and update accordingly.
The Cisco Collaboration Architecture shows communication capabilities and how they may be instantiated in the stack. What I like most about this architecture is the concept of the collaboration services layer. I'm a believer in a services approach. I believe many capabilities should be developed once, optimized, and then exposed through interfaces to applications and devices that use them. I refer to these as exposed services, or services with a well defined set of protocols and APIs that interact directly with applications usually in a request/response method to provide some functionality. This approach means the same functionality may be shared across applications that call on the service. As an example, the presence information I see in my Instant Message (IM) program is the same presence I see in my Enterprise Social software, phone directory, e-mail client, hover card and whatever else may require presence, such as expert location in my customer care application.
After the use cases have been defined and the architecture model created the next step is to "flow" the use cases through the architecture to see if the requirements are currently met or need to be prioritized and invested in. The most direct way to demonstrate this is through a tool I call "Architecture in Action". This is an Adobe Flash tool, so it may not work on certain tablets.
In this tool I've taken 5 "day in the life" scenarios with various collaboration use cases and mapped them to the Cisco Collaboration Architecture. The day in the life use cases currently modeled are:
- Supply Chain Specialist
- Sales Professional
- Specialist Optimization
- Insurance Professional
- Marketing Manager
You may use this same approach for other "day in the life" scenarios of your users. By understanding the day to day activities of different employees and their needs for communication capabilities you can easily determine how well positioned you currently are and where to invest in new technologies. It is very important that the various stakeholders come to you with their problems and not solutions. Such shadow IT activities create additional technology silos that don't integrate and have additional costs and complexities. Let me know your thoughts on the "Architecture in Action" tool and how you're prioritizing your collaboration investment to deliver the greatest impact to the business.