Students

Ready or not, new IT paradigm requires knowledge sharing — part two

A paradigm shift has rocked the information technology world, changing the way companies acquire the technical capabilities to complete business processes. Service-oriented architecture (SOA) is changing the way IT professionals work together, challenging them to find ways to confidently share information across workgroups, departments or even corporate boundaries. For some companies, success in this new environment might mean organizational change. Part Two of Knowledge@W. P. Carey's series on changes in the IT industry examines new research about the ways firms can prepare to succeed in an SOA world.

2006-02-01

Ask the mother of any 3-year-old, and she'll tell you that sharing doesn't always come naturally. But in the information technology realm — a world where people tend to believe that, indeed, "knowledge is power" — knowledge management and sharing have become critical for companies shifting to what is now called a service-oriented architecture. An SOA differs from the traditional software-development model, where software is a product that IT professionals design themselves or purchase ready-made from a software vendor. Under the SOA model, the components or units of work in an application are treated as services that can be accessed in-house or purchased from some other company that may or may not consider software development its primary business. Work passes from service to service until the task at hand has been achieved. What's different? The work might take place outside company walls. For instance, an online retailer checking inventory availability could parcel out that part of a transaction — that service — to some other company or to the cheapest provider at any given moment. This method of application design represents a new IT paradigm, one that will require IT workers to embrace organizational change based on new ways of managing knowledge within a company. Given this shift on the IT playground, even the most emotionally mature knowledge workers may struggle with the challenges of sharing knowledge across workgroups, departments or even corporate boundaries. When researchers examined one Fortune 500 company at the forefront of SOA evolution, they found that an organization's readiness for knowledge sharing is something best evaluated on a workgroup-by-workgroup basis. The age of agility According to Gartner, Inc., a leading IT research and advisory firm, SOA will become a widespread software development practice in as little as two years. SOA often builds on the process known as agile software development, or ASD, which targets reduced development time through the use of small teams who work on small, incremental software engineering goals: development of services, for example. "Many companies are involved in pilot projects to develop services, and they're beginning to understand the cultural shift that SOA requires," says Michael Goul, professor of information systems at the W. P. Carey School of Business. Goul's colleague, Haluk Demirkan, an assistant professor at the school, adds that in the past, most IT department changes were either organizational or involved infrastructure, such as the purchase of a new computer. "SOA requires both organizational and infrastructure change," Demirkan says. That's because SOA and ASD vary significantly from traditional software engineering. The differences come under review in a paper on knowledge management readiness by Goul and Demirkan. Mark Keith and Jason Nichols, doctoral candidates in information systems at the W. P. Carey School, also contributed to the project. As Goul and Demirkan explain, traditional project management methods work best with large projects that are planned upfront. Expert knowledge is needed in the planning phase, but after that, the worker bees can take over. When clients change their minds — and project requirements — it's called "scope creep," and it's something to be avoided, not anticipated. Contrast that view with ASD, where scope creep is a given, changes happen often, developers respond quickly to those changes and, consequently, knowledge must be on hand at all times. Add in the service-oriented application method, where applications come together via units of work to be performed by a person, computer or team, and suddenly knowledge must not only be available, it needs to be shared freely and viewed as just one more piece to maneuver on the chess board. Strategic moves Goul and Demirkan liken today's knowledge worker to a chess master. Like the chess champ, knowledge workers must learn the rules of the game — the players, policies and moves that won't get a company into trouble. Then, both the chess and IT virtuosi learn principles of their crafts, including strategies, threats and risks. But ultimately, what elevates a chess player to chess master is knowing the patterns of the game and applying them as needed. The tough part: There are hundreds of patterns to learn. Therein lies a challenge for the knowledge worker. Among the thought changes Goul and Demirkan see ahead for knowledge workers, you'll find:

• A belief in re-use: Services are platform-independent and designed to be mixed at will, so they should be designed for use by multiple players. Demirkan cites PayPal as a classic example. It's available to any online retailer who wants it. "Reusable services create a snowball effect of speed and flexibility" in software development, he says.
• Market orientation: "Instead of being in a cubbyhole, writing your specific piece of code, you're looking at the project with a market-orientation," Goul says. "Would outsourcing be a better expenditure of your time and effort because someone in another country has a best-of-breed software that can do what you want at a cheaper cost?" Then you want to buy it and bring it in, and figure out a strategy to negotiate the transaction.
• Incentives and rewards: "One of the main reasons people don't share knowledge is because knowledge is the commodity they offer the company," Demirkan says. He maintains that today's knowledge worker needs to understand that knowledge sharing won't endanger job status, and today's employers need to recognize that incentive structures probably will need to change.

Also ahead: the service-oriented enterprise. "If we're going to organize the IT structure according to services, we need to match with how we organize the structure of our people," Goul says. "That's where the term 'service-oriented enterprise' comes in. How do we develop the organizational structure to match this changing IT infrastructure? Group by group As it turns out, the first step to successfully implementing a service-oriented enterprise and all the knowledge sharing it requires is self-assessment, say Goul and Demirkan. And, it isn't enough to evaluate this on a companywide or even departmental basis. Having looked closely at one company that is truly an SOA groundbreaker, Goul and Demirkan believe that companies should examine the readiness for knowledge sharing in each individual workgroup. Several factors come into play in evaluating a group's inclination to share information. One is the helping patterns used by specific groups, a notion covered by Harvard University Professor Leslie A. Perlow, who outlined the concept in a paper titled "Contextualizing Patterns of Work Group Interaction: Toward a Nested Theory of Structuration." After studying large software engineering firms in different countries, Perlow named three workgroup patterns — managerial-centered, expertise-centered and team-centered. In the first, there is "little or no communication among software engineers," write Goul and Demirkan. Interaction occurs between engineers and their project leaders. In the second pattern — the expertise-centered model — engineers help each other freely: "Each team member is known for some kind of expertise that other members rely on for help." In the third pattern, similar free-flow of information takes place. Team members turn to whomever they think can help in a team-centered group. Most companies use simple surveys to evaluate readiness for knowledge management, and most aggregate the survey data on a departmental basis. As Goul and Demirkan found out, researchers are likely to get very different levels of agreement to a statement such as, "Our organization members are helpful," when measuring those in team-centered groups versus those who interact only with a manager. According to Goul and his research team, the person from a team-centered group is giving a cumulative response about co-workers while the person from the managerial-centered group is providing feedback only on a project leader. "If a managerial group project leader is perceived by subordinates as doing a poor job or is disliked, then response from that group will be mostly negative, when in reality, maybe only the project manager is unhelpful," according to the Goul/Demirkan paper on evaluating readiness for knowledge management. But, given the impact of a difficult or bumbling boss on survey results, IT managers armed with partial information could easily misjudge a team's readiness for knowledge sharing and the collaboration it requires. The same is true if all an IT manager has is a survey showing responses of the department in aggregate, not those of individual teams. Enablers that support or thwart Along with workgroup helping styles, Goul and Demirkan refer back to research done on "knowledge enablers," which include constructs such as collaboration, learning, trust and formalization of rules and policies workers must follow. These, too, deviate by workgroup. In the study performed by Goul and Demirkan at that Fortune 500 financial firm, results from different groups varied by as much as two rankings on a 7-point Likert scale. Overall, "collaboration" earned a score of 4.69 at the study company. That sounds pretty good until you discover that one of the five workgroups surveyed rated their collaboration at 5.72 while another ranked itself at 3.56. Imagine putting those two groups together and passing services back and forth in an agile development process. Knowing which group needs skill-building in specific areas can help companies get knowledge workers up to speed in the new SOA environment, Goul and Demirkan maintain. And what's at stake are "big bucks," Goul says. After all, return on investment is corporate proof that a move was a smart one. "How quickly can the new paradigm turn ROI?" Goul asks. "It depends on how well things like assessing your readiness can be mapped into the change strategies that get your SOA going." As SOA evolves into a mainstream software engineering practice, it will, as Goul says, "ratchet up the intellectual exchange."  It also will reinforce the value of lessons learned in early childhood: Share with others, and remember to play nice.

KnowIT