Introduction
Legacy thinking is by far the most critical component. There is a culture and perspective driven by the misunderstanding of how the defense industry relates to business processes and practices. Far too often, legacy thinking separates or diminishes the importance of business concepts in defense work.
Generally, the hammer alone cannot build a house. Legacy thinkers may understand that technology is a tool set but they do not have the understanding as to where to apply the tools or what tools are practical for any given task.
Legacy thinkers are less likely to extend trust. Legacy thinkers are not comfortable sharing and not comfortable trusting; this can be from lack of understanding how information sharing requires trust or it can simply be empire protection. The only way to defeat legacy thinking is to educate leadership from all directions. Although it is a challenge, it is realistic and possible to help leadership understand the value in changing their approach to today’s business, technology or defense problems.
Contemporary thinking applies business concepts to defense challenges; contemporary thinking is service-oriented thinking. Obviously, there are some fundamental differences with commercial and defense-oriented business. Yet satisfying the defense mission requires assistance from commercial business. Regardless of who is involved, DoD leadership is ultimately responsible to our service members.
It is interesting to see that we spend a great deal of time and effort looking for better ways to communicate and yet we can see that the communicative gap is increasing. Technical solutions do not necessarily yield the best answers to technical problems. Our inability to communicate is causing widespread problems in many industries and the DoD is no exception. This issue is very relevant to the service oriented architecture approach to problems because services are dependent on trust and harmony. Project leaders, developers, and managers must establish trust relationships with each other in order to truly benefit from SOA concepts.
There are a lot of disjointed efforts out there! What we do not have is a good central focus for Service Oriented Architecture practices. Leaders need to get their arms around this; they need to eliminate the stove pipes and silos. If the leaders who control the budget are involved and engaged early on, there will be more success.
Industry provides generic solutions to DoD problems, many times, without really understanding the full dynamics of the problem. It is up to your team to define the business centric requirements to shape the generic technology into a specific solution.
Understand that SOA is more than a technical solution. SOA is an approach to a problem, a philosophy, not just ones and zeros. It is about people working together, collaborating effortlessly, and purposefully. After all, SOA is about services that make sense.
It is true that SOA can fail, but there is more reason and opportunity for success. Readers do not need a cheerleader, an evangelist; or an adversary — Leaders need to work with each other, open up their trust and expand data boundaries. They need to know “how” to set realistic goals and create winning strategies. They need to have solid people strategies to involve key stakeholders. Knowing what information you have, what information you need, and what information is available is critical to “how” we start setting goals.
The Problem
The Department of Defense (DoD) leadership understands the importance of Service Oriented Architectures (SOAs), Cloud computing, Software as a Service (SaaS), and other emerging technological methodologies, standards, and practices. While this is clearly evident in speeches, PowerPoint presentations, published policy, standards and guidance, the reality is that the DoD is still in its information sharing infancy. Additionally, commercial corporate interests may not naturally align with the concept of information sharing. Historically, information has been restricted to small groups or individuals. Businesses that have served the DoD have strategic advantages due to the restriction of information. There is the fear that information sharing may disrupt business cycles, or create new business opportunities in markets that were previously unreachable. In a general sense, the critical need to properly and securely share, reuse, and provide information services are often blocked by issues of security, lack of understanding, misinformation, and legacy thinking.
Legacy thinking is by far the most critical component. People are the most important aspect of a service-oriented approach, but legacy thinking does not lend itself to the “people component.” Who are the people? The people, for this discussion, are first and foremost the members of the armed services and civilian support staff. While there are many stakeholders in the DoD, it is “the warfighter” who is the ultimate customer. There is nothing more important in the DoD than meeting the needs of those who are in service. There is a culture and perspective driven by the misunderstanding of how the defense industry relates to business processes and practices. Far too often, legacy thinking separates or diminishes the importance of business concepts in defense work.
Currently, all throughout the DoD it is very common to find images of Dilbert; this comic strip and others like it can be found in cubicles and offices of government civilians and contractors alike. There are some common patterns that occur within defense work, making Dilbert very familiar and amusing. There is a real sense of frustration when dealing with mid-level leaders who “don’t get it.” Getting “it” is the realization or understanding that technology is simply a tool box filled with many different tools. Archibald Putt said famously– “Technology is dominated by two types of people: those who understand what they do not manage, and those who manage what they do not understand”. Generally, the hammer alone cannot build a house. Legacy thinkers may understand that technology is a tool set but they do not have the understanding as to where to apply the tools or what tools are practical for any given task.
Legacy thinkers are less likely to extend trust. Today, more than ever, trusting in virtual teams and staff outside of your immediate organization is crucial for success. Legacy thinkers are not comfortable sharing and not comfortable trusting; this can be from lack of understanding how information sharing requires trust or it can simply be empire protection. Unfortunately, this is the way it really is. The only way to defeat legacy thinking is to educate leadership from all directions. This is a difficult task given that leadership is dealing with recent economic conditions, aggressive time-lines, and administrative overhead such as 300 emails a day. Although it is a challenge, it is realistic and possible to help leadership understand the value in changing their approach to today’s business, technology or defense problems. Leaders can understand what they manage. Today’s leaders must understand what they manage and expand their trust beyond their previous borders.
Contemporary Thinking
There are some fundamental differences with commercial business and defense oriented business. Contemporary thinking applies business concepts to defense challenges; contemporary thinking is service-oriented thinking. Commercial business may be driven by corporate stakeholders and public shareholders while defense oriented business is driven by the need to satisfy the defense mission. Yet satisfying the defense mission requires assistance from commercial business. The stakeholders and shareholders are different and the measures of performance or effectiveness are different but the action plans, the business plans, and the logic to approaching technical problems can be very similar. Regardless of who is involved, DoD leadership is ultimately responsible to our service members.
Helping leaders to get “it” is everyone’s shared responsibility. We start this process by clearly identifying the idea that technology is the least of our problems when addressing issues related to services. It is interesting to see that we spend a great deal of time and effort looking for better ways to communicate and yet we can see that the communicative gap is increasing. Technical solutions do not necessarily yield the best answers to technical problems. Our inability to communicate is causing widespread problems in many industries and the DoD is no exception. This issue is very relevant to the service oriented architecture approach to problems because services are dependent on trust and harmony. We must breakdown the barriers of communication, address the culture of legacy thinkers, and get our project teams across the various domains together. Email, instant messenger, phone calls, and sticky notes on your desk will not do anymore. To accomplish our long-term business solutions we must first accomplish our short-term technical wins, teams must communicate better up front.
It is clear that deadlines are shorter, manning is reduced, and budgets are tighter. Technical teams, developers and management teams have a history of talking past each other. Four team leaders were in a meeting discussing service oriented solutions. This highly technical meeting went on for about 30 minutes. After the meeting was over three of the team leads left the office leaving the one lead and his staff. The remaining team lead asked a staff member what he thought and the member replied “I have no idea, all of you were talking at the same time”. SOA is about creating efficiencies not only through technology but through people and their relationships. The result is better productivity, reduction of tasking, increased organizational agility, reduction of cost, and better collaboration. A required component to a successful SOA is trust. Project leaders, developers, and managers must establish trust relationships with each other in order to truly benefit from SOA concepts. Leaders must fundamentally understand the core concepts of the projects they are involved in to provide the vision for the project and extend trust in order to enable the team to create the SOA Solutions.
DoD leaders must define goals in a business centric manner. There are many reasons why leaders push back on business-oriented concepts in the DoD. Architecture creep can occur when leadership may be driven to focus on short-term goals that force new stove pipe solutions. Tasking is performed as a result of necessity, not planning. Business goals may need to be satisfied immediately to meet undefined or poorly determined requirements. This can only cause problems in the long run. Teams, whether two or two hundred, need coordination, guidance, input, and an executable vision to accomplish long term goals. There are times that teams must meet short term obligations. These obligations should be satisfied by a predetermined enterprise aligned solution. In the real world, teams may have very little resources including labor, funding, and assets. Depending on the level of planned implementation, teams should strategize using a business centric model. What does this mean? It simply means that whatever their goal, it must make business sense, not only to the team but across other communities of Interest. If guidance is clear and design standards are set, projects can and will be successful regardless of constraints. There is never enough funding and never enough time.
SOA is not just about the technical applications of design standards – it is about a solution-based approach that looks at the issues from many perspectives. Developers, technicians, task leaders, managers and users all have intertwining roles that are independently critical. Leaders must understand that in order to succeed, they must be transparent. Transparency is not easy, especially coming from a legacy environment where sharing information is not the norm. Leaders must understand the stakeholders, and how they have to interact to be most effective. Leaders need to accept the fact that process-wise, “everyone needs to open their doors”. Leaders must understand who they are interacting with, not just who they direct.
The How
There are a lot of disjointed efforts out there! We need a DoD Service Oriented Architecture Competency Center. Although this centralized knowledge center does not currently exist, we do have tools to share information such as Defense Knowledge Online, Air Force Knowledge Now, Navy Knowledge Online, etc. Even without formal direction such as policy, standards or guidance, teams can build DoD aligned strategic business environments. The DoD has rules and regulations that are hard to understand and often require analysis. Rules may differ from command to command. Even (DISA) Defense Information Systems Agency has rules that vary. SOA pilots and small projects are appearing in many areas of the DoD. Effectively, the people involved in these projects are becoming educated in SOA methods and practice. These same people are becoming subject matter experts and are building communities for shared practices. As developers, users, leaders, and project managers learn more about SOA concepts they should develop coaching strategies to inform and teach their teams. Coaches at each command can help teams by sharing information across their enterprise. These people effectively become touch points for their communities. There aren’t any formal SOA Coaches today but informally these are the people that are helping SOA become a reality across the entire DoD enterprise. This pragmatic approach is how SOA in the DoD will become an increasingly natural practice.
Create, Steal, Plagiarize, Reuse a Business Plan
When looking to create something that will benefit the organization, reach back into the organization. It may seem obvious, but most people do not realize the tools and connections that already exist. Start with some good questions: What tools already exist in the organization? Is anyone else working on a similar project? Who are the key stakeholders that have an interest in these tools? Why? How can it benefit them? Discover as much as you can and spend some time making calls, doing research, and reaching inward. In your business plan, you will add a section for “discovery”. Let’s call this “due diligence”.
Get people involved! Form informal working groups to get buy in from co-workers and other staff. Advertise what you are doing internally. Far too often developers believe they know what is best for users. In reality, most developers know what is best for developers. Service oriented thinking suggests that leaders and developers must work together through every phase of development. Developers must appreciate that the end user knows what outcome he/she wants. As the expert, developers have an obligation to ask end-users questions that will help them to understand and be crystal clear about the deliverable products. Yet, the end-user has an obligation to communicate effectively with the developer what outcome they desire. To accomplish this, both must be humble and open to collaboration.
Industry provides generic solutions to DoD problems, many times, without really understanding the full dynamics of the problem. It is up to your team to define the business centric requirements to shape the generic technology into a specific solution.
Understand that SOA is more than a technical solution. SOA is an approach to a problem, a philosophy, not just ones and zeros. It is about people working together, collaborating effortlessly, and purposefully. After all, SOA is about services that make sense.
Conclusion
There are articles on Service Oriented Architecture that have already doomed the concept to failure. It is unfortunate that we do not have more patience. It is true that SOA can fail, but there is more reason and opportunity for success. Readers do not need a cheerleader, an evangelist; or an adversary — Leaders need to work with each other, open up their trust and expand data boundaries. They need to know “how” to set realistic goals and create winning strategies. They need to have solid people strategies to involve key stakeholders. Knowing what information you have, what information you need, and what information is available is critical to “how” we start setting goals. SOA will help us share what we have and get what we need when we need it. After all, we are not trying to re-invent this wheel, we simply want to use it.
The Cohenization Project 