E-MailArchived Quotes of the Day
While companies may emphasize one strategy more than another, both proacting and reacting are important to most companies. Additionally, many companies get into a reacting mode by accident. Competitors launch new products or new features earlier than anticipated and then companies are in a new mode: catch-up. When reacting degenerates into catch-up is when companies face trouble. Getting out of catch-up mode can be very difficult because it usually puts pressure on speed of development, which leads to a deemphasis on quality, which results in slower speed, leading to another round of more catch-up and further downward spiral.
Proacting and Reacting, anticipating, and adaptation -- these are strategies that agile leaders need to consider. They need to develop guidelines so development teams understand these strategies and how they relate to business objectives.
Getting an organization to shed deeply rooted notions of conventional, heroic leadership is difficult and like weeding a garden: it requires vigilance and hard work. While the collaborative leadership program painted here appears to go against ingrained behavior patterns that are wired deep within our minds if not our DNA, we must persist despite the daunting effort. I am not so sure we can afford this biological or psychological -- and silo-creating -- baggage any longer.
The future of effective human-computer systems is at stake. IT leaders and business leaders need to understand that collaboration and involvement of others in the conceptualization, design, and implementation of change (and IT systems are change too) isn't just something to be checked off a list. Collaboration across groups needs to be embedded deeply into how the organization designs and implements change.
"Heroic Leadership Creates Perpetual Silos,"
Business-IT Strategies E-Mail Advisor, 6 January 2010
Good software architecture is a concept that has been and continues to be overdue. Like good design, GSA is difficult to achieve. How many of us have been frustrated by bad bottle openers and quirky corkscrews, let alone challenges associated with software interoperability? We know good design when we interact with it, but most efforts fall far short of the satisfaction you get when you pick up an Oxo Good Grips vegetable peeler, use a Swiss Army knife, pour water from an Alessi kettle, or place a Post-it Note on a colleague's desk.
A mentor of mine put it well when he sagely observed that simply because someone is given carpenter tools doesn't make them a master carpenter.
"SOA Tipping Point,"
Business Technology Trends & Impacts Council Opinion, Vol. 10, No. 10
The delivery of social media technologies (SMT) also challenges technology acquisition, deployment, and support models. Social media -- while far from free -- can be relatively inexpensive, certainly when compared with the enterprise licensing models of the past. It's also easier to deploy by increasingly technologically savvy business professionals who no longer need data center high priests to make technology work. Anyone can go to the Web and deploy SMT. This represents a threat and an opportunity. It threatens the control of IT but helps businesses think creatively about innovation, customer service, product lifecycle management, and countless other business processes. The acquisition, deployment, and support of SMT will necessarily be shared among internal and external technology providers -- and by business and technology professionals. Everyone will need to widen and deepen their social media competencies.
[The client-vendor relationship in the IT outsourcing context] is qualitatively different from the typical client-vendor relationship that characterizes the bulk of economic exchanges. In fact, the client-vendor relationship in the IT outsourcing context is a prototypical example of value cocreation arrangements, where two or more organizations actively cooperate over an extended period of time in the development and realization of economic value. The need for a value cocreation paradigm for IT outsourcing seems inevitable as IT is typically so deeply embedded in firm operations that an arm's-length relationship with the IT services provider only proves unable to adapt to the changing needs of the customer organization over time. Yet, despite the intuitive theoretical appeal of the value cocreation paradigm in this context, ... we are today very far from this ideal state.
History tells us that the Romans were not great conceptual thinkers, certainly not on a par with the Greeks. The Romans were great at a few key things: war, administration, and engineering, and all of these things hung together. War made it possible for a small city state in Italy ultimately to conquer a very large portion of the known world; administration made it possible to govern and administer Rome's huge, far-flung, and diverse empire; and engineering made it possible to build the roads, aqueducts, walls, and castles to secure and provision that empire.
Why is any of this important to today's C-level executives and what role does enterprise architecture play in any of this? Well, the first thing is that over time, the Romans learned to think long-term. When they captured a new province, the first thing they did was to begin to build roads and fortifications, castles, and aqueducts to allow them to protect and supply what they had conquered.
Modern enterprises would do well to emulate the Romans' thinking. Take a major merger. In addition to working to integrate the financial and marketing aspects of this new business empire, top management should set the IT planners and engineers at work to integrate the data and systems from these different merged units. IT is today's most critical infrastructure.
"Why Is the Roman Coliseum Still Standing?,"
Enterprise Architecture E-Mail Advisor, 6 January 2010
One interesting element of drift is that those "drifting away" from the standard procedures believe that it isn't really that much of a problem because they believe that someone else will be following the procedures. In other words, someone else will be conservatively managing the risk, even if you aren't.
Drift might be a good explanation for the financial meltdown, as everyone pushing the limits thought everyone else -- especially regulators and internal risk managers -- would be doing their job ensuring too much risk wasn't being taken on.
There's often an unfortunate tendency for IT governance to focus on prioritization of existing resources and the demands for those resources. Years ago a CIO remarked to us, "If prioritization merely reorders the same old projects, who cares? What we need is better projects!" In IT governance terms, he's asking for engagement with the business to provide better insight into what is possible and, more important, what is potentially transforming for the business. Without question, this is an important, maybe even dominant, aspect of IT governance.
"Leveraging IT Governance When the Chips Are Down,"
Cutter IT Journal, Vol. 22, No. 12
We are literally surrounded by examples of how disrupted flow affects our daily lives. However, software delivery in general seems to ignore how disruptions in flow cost time and therefore money. When I speak to teams about using the concept of core hours -- a period of time during the workday when the team works on nothing but the main project -- I ask about how they feel when they're able to work uninterrupted for a reasonable number of hours. I consistently hear terms like "in the zone" and "on fire," and there is palpable delight when people speak of those times. That's what flow feels like. If it feels that good, why not seek to achieve it as often and for as long as possible?
"Confessions of a Flow Junkie,"
Agile Product & Project Management Executive Update, Vol. 10, No. 22
IT organizations have to be specially vigilant to recognize where geography makes things difficult. IT may have to adopt special mechanisms for overcoming the separateness; perhaps this means colocating or exchanging of staff. Perhaps this means emphasizing the customer-contact roles beyond what is necessary simply to carry on the communications and planning. Perhaps this means accepting some aspects of decentralization. But something has to be done, because unchecked, the silos of business and IT will be even stronger. And that's unfortunate.
I expect adoption of on-demand/cloud-based BI and data warehousing to experience steady growth in 2010. Several trends will be responsible for this. First, the state of the economy is having a strong effect on corporate BI and data warehouse funding, and many IT organizations are considerably underresourced while at the same time under a lot of pressure to cut costs. Consequently, looking to do more with less, they realize that BI is a very important but costly necessity, so they are turning to on-demand/cloud offerings and services. Second, providers are continually introducing more comprehensive on-demand/cloud-based offerings. And third, the concept is not so new anymore. Consequently, it appears that end-user organizations are becoming more open to utilizing outside applications and services to meet at least some of their BI and data management needs.
I expect adoption of on-demand/cloud-based BI and data warehousing to experience steady growth in 2010. Several trends will be responsible for this. First, the state of the economy is having a strong effect on corporate BI and data warehouse funding, and many IT organizations are considerably underresourced while at the same time under a lot of pressure to cut costs. Consequently, looking to do more with less, they realize that BI is a very important but costly necessity, so they are turning to on-demand/cloud offerings and services. Second, providers are continually introducing more comprehensive on-demand/cloud-based offerings. And third, the concept is not so new anymore. Consequently, it appears that end-user organizations are becoming more open to utilizing outside applications and services to meet at least some of their BI and data management needs.
The "trends" component ... is not the fact that the airborne Internet is coming, but that it's actually here. Soon we'll be seeing "full-service" airlines charging for the service and discount airlines giving it away. And, now the already beleaguered airlines are going to have to adapt. Some will move quickly and others will lag behind. My current favorite airline, Southwest, has been leading the charge in putting plugs and work areas in their waiting areas -- a welcome feature. But they don't yet have universal wireless available. But that may be unnecessary in the future. With netbooks and 4G networks, everyone may be online all the time anyway, at least on the ground. With the airborne Internet, the real trick will be how to leverage this connectivity and not make us or our employees any more jumpy than we/they already are. We have to give people what they want when they want it, Internet-wise, but we also have to do so with a light touch.
"The Really Mobile Internet,"
Business Technology Trends & Impacts E-Mail Advisor, 10 December 2009
Organizations need to become much more aware of what they're spending on IT, how they're spending it, and the impact their investments are generating. Traditional IT finance organizations are quite limited in their budgeting capabilities. In fact, they're essentially accountants that develop and manage annual budgets. The new skills and capabilities call for active, strategic accounting and finance. They call for optimization and creative financing. They call for exquisite metrics-based accounting and performance monitoring and management that provides real-time data about the capabilities and availabilities of the IT organization.
Implementing green IT across the organization should be seen as a comprehensive business transformation effort that affects the entire organization and not just one or two of its parts. For example, the business leadership of the organization should prepare for changes to the business model as well as the product portfolio of a business as the business undertakes a greening effort. This change is akin to the change that occurs with any other technology-based business transformation. Therefore, another key message that emerges ... is that metrics and measurements play a significant role in the green transformation (which is a business transformation) of the organization.
Finally, green transformation also implies IT systems upgrades, use of emerging technologies, implementation and integration of CEMS, and changes to the organizational structure. This results in a related but large area of investigation that can be called environmental intelligence. Needless to say, further investigation and validation of green IT metrics is required.
Organizations need to become much more aware of what they're spending on IT, how they're spending it, and the impact their investments are generating. Traditional IT finance organizations are quite limited in their budgeting capabilities. In fact, they're essentially accountants that develop and manage annual budgets. The new skills and capabilities call for active, strategic accounting and finance. They call for optimization and creative financing. They call for exquisite metrics-based accounting and performance monitoring and management that provides real-time data about the capabilities and availabilities of the IT organization.
But there are problems with the current keepers of technology. Some of them insist that operational technology is still underappreciated, that discipline is required now more than ever, that standardization is still an essential best practice, and that reporting relationships need to centralize -- and then recentralize. They wave the compliance and regulatory banners every chance they get. They're suspicious of the new "shared" technologies, such as Web 2.0 and especially social media, and they don't trust their business partners to do the right things when it comes to technology acquisition, deployment, or support. They just don't. In fact, much of the "fix my computer" crowd believes that the so-called business technologists who sit in businesses and wax poetically about technology really understand only what technology might do and virtually nothing about how technology works or what's involved in delivering cost-effective technology to enable business processes.
The other side of the aisle is where strategic business technologists live and breathe. They discount all technology that doesn't touch a customer in one way or another. They are bored with the old arguments about standards, alignment, chargebacks, and project management. They want operational technology to just work (and scale securely, of course), and they want the people who make it work to work cheaply -- and efficiently -- regardless of where they're physically located.
"Partnering" -- besides being a mandatory buzzword -- is a curious term. Nowadays, instead of taking over a company, we partner with them. We don't sell anything anymore; we partner. And now, rather than outsourcing, we create strategic partnerships. While the goal of an amicable and mutually rewarding relationship is admirable, what each party truly expects from the other in an outsourcing arrangement formed under a "partnering vision" is quite different.
The client often wants a "well-behaving provider." But what the client means by "well-behaving" is a provider that accepts nearly infinite scope creep without a commensurate increase in price, immediately reacts to the client's ad hoc needs (at no charge), and performs what the client really meant in the specification instead of what was actually written and quoted (again, at no charge) -- all the while acting under a fixed-price, punitive contract. This interpretation illustrates the client's version of partnering as an environment where "the client is always right." A "master/slave" relationship appears to be the goal.
Data integration and data integrity requirements can pose significant problems for organizations implementing business performance management initiatives due to the sheer number of sources required to be integrated and the nature and composition of those source systems. As a rule of thumb, I recommend organizations to plan on integrating approximately 10-15 sources to adequately support performance management initiatives.
Planning, budgeting, and forecasting systems, followed by spreadsheets, legacy systems, ERP applications, and CRM systems rank highest among data sources organizations are required to integrate to support their business performance management efforts.
The fear of change and thus the need for change management may have little to do with the magnitude of change itself and everything to do with the magnitude of the desire for excellence within the people themselves. How do leaders cultivate a desire for excellence within teams? Leaders need to inspire, motivate, and ignite the transformation within those on the fence between indifference and desire. What are the 20 steps for creating a passion for excellence? The economy is helping out with one of those 20 steps: establishing a deep fear of irrelevancy.
It really doesn't matter where you are or what device you're using. You can still track sales, change prices, and replenish inventories whenever you like -- with the right technology infrastructure, applications, and delivery mechanisms. The era of fixed-location computing is over. Constant communication is common. The implications for total mobility are far-reaching. On the one hand, there are obvious implications about technology support: technology must always be on, reliable, scalable, and secure. On the other hand, mobile computing assumes management and governance protocols that by definition must be flexible and adaptive. Mobility is all about agility.
One way to jump into mobility services is to define what the virtual office would look like for your industry and for your company. You can then back mobility services into the virtual office model.
Typically, the company that built them, with bugs fixed "free" for some warranty period, often two to four months, maintains outsourced projects. Even in good projects, only 90% of bugs are discovered and fixed before release. But due to the accelerated ramp down, a much smaller percentage of bugs are being found on offshore projects. And, with at best 800 bugs undiscovered (probably more like 2,000), the costs are going to show up during the maintenance phase. When you consider that outsourcing only saves about $250K on a $3.5M project, and the maintenance costs are likely to be at least three times as much (based on 3x bug count), it will cost you more, to get a poorer quality product ... just the facts!
It is critical to acknowledge that the use of outsourcing should never imply less effort in managing IT, only a different emphasis. For example, the top IT manager will need to concentrate more on direction, strategy, and implementation than with routine service delivery and staff management. The internal audit function, which may have limited reviews to comply with company policies in the past, must have a more active role. Auditing (compliance, validation, and value for money) is generally more extensive and frequent because the organization's accountability hasn't changed, but direct control and physical proximity are now absent, and the introduction of profit as a key motivator behind everything the provider does (e.g., its advice/recommendations, service delivery, and resourcing strategies) must be taken into account. Planning becomes absolutely critical in outsourced environments. It is the familiar "garbage in, garbage out" paradigm; the only difference is that "outsourcing garbage" costs you much more. There is an increased need to appropriately authorize plans, costs, recommendations, and actions, and then sign off on deliverables -- if only for the reason that most providers will not begin work without appropriate approvals to make sure they get paid. New requirements, and those that require changes from what was originally agreed to, will need to be negotiated and will have a cost impact.
Let's consider the idea of IT as a capital asset. Imagine, for example, the decision making, planning, and architectural design process that a utility company undergoes before deciding to build a new nuclear power plant. This investment realizes a capital asset involving hundreds of millions of dollars, creating a resource that is critically strategic to the business and that needs to be maintained and depreciated over the asset's long-range lifecycle, which is measured in decades. If we accept that planning for a nuclear power plant is valuable, why don't we apply the same due diligence to our IT capital asset? For some large enterprises, IT may entail a comparable investment of tens or hundreds of millions of dollars in the course of a single decade, and it is likely to be even more strategic to the business.
The agile movement was slow to embrace product, project, and middle management, but that began to change several years ago and is continuing. One solution to this challenge has been to "redefine" agile as lean-agile or use other terminology that proponents believe is more management friendly. I don't think what we name it is the problem. I think one of the problems in wider acceptance of agile (and there are several barriers to overcome) is defining middle- and upper-management roles. Too often, management's involvement has been described as "buy pizza and get out of the way," "support self-organizing teams," or "remove impediments." One gets the impression from some agilists that middle managers themselves are the primary impediments to change.
I think that middle managers aren't barriers to agility, but catalysts to agility. If we don't engage middle (and upper) managers in the agile transformation, if we don't extend agile principles and practices across organizations, then these transformations will falter. The key is agile leadership and there is much to do.
But is the capacity for human social systems and the human brain to operate appropriately when awash in this information growing commensurately? I would argue that this capacity has scarcely advanced in 2,000 years. At a recent gathering of CIOs and other corporate executives, this conundrum surfaced. Since the ability to ignore data, reason defensively, and otherwise fail to make good decisions seems perpetual, is there any hope for organizations to take better advantage of what IT can deliver? Various forms of corporate dysfunction are impeding progress.
"Software's Easy; Wetware's Hard,"
Business-IT Strategies E-Mail Advisor, 18 November 2009
IT governance is indeed used in most organizations. The specific practices may differ slightly, but the traditional practices -- prioritization, steering committee, financial management -- are largely used to some extent by everyone. What's a bit startling, though, is that at least half of business managers -- both corporate and business unit-based -- do not believe IT governance overall is effective. And at the same time, most business managers do not believe their IT is better than that of the competition, at least in terms of how information and IT is used.
Yet a significant number also finds that individual practices add to the value IT delivers to the organization. As well, business management involvement (which is part of our definition of IT governance) is quite widespread and is thought to add to the value IT delivers as well.
"Governance Connected to Better IT Value,"
Cutter Benchmark Review, Vol. 9, No. 9
There is a significant culture clash between those who think of business processes versus those who think of automated workflow. It is the difference between how the end users and business analysts view their business and the way that programmers think end users and business analysts view their business. I hardly ever show UML diagrams to the users, though I know a lot of analysts who swear by them. I use very basic BPML-like swim lane diagrams, and I always draw them vertically rather than horizontally. But my diagrams always include people.
Commoditization, consumerization, and alternative models to deliver technology have changed forever the way governance is defined and implemented. The number of stakeholders has increased dramatically, and the role of technology has expanded into three distinct categories (operational, strategic, and innovation). The governance mission is evolving toward a shared, participatory approach that recognizes the roles that all stakeholders play as they acquire, deploy, and support technology. Governance should acknowledge the role that each plays in the optimization of the business technology relationship.
I believe we need to look at people, process, and technology metrics to get a holistic or complete picture of the effects of social technologies. Unlike a database, where we are just interacting with structured data, social technologies require us to interact with other people. If those interactions start to change (or appear or disappear) because of these new technologies, they can ultimately change the structure of our organizations. So the metrics for the use and outcomes of social technologies do not come only from IT or the line of business but also from HR/organizational development and even from such cost sinks as training and support. What information is critical to determine not only if you are having a positive effect on the organization, in alignment with its goals and initiatives, but to determine whether you even want to continue in the same direction?
"The Value of Social Networks in the Enterprise,"
Cutter IT Journal, Vol. 22, No. 10
When transitioning to agile, some traditionally educated project managers face a rude awakening when they first run an actual agile endeavor. They looked forward to the increased transparency and the daily reports they'd receive from their team, but suddenly they're hit by reality in the form of real customer contact. The team may ask silly questions such as, "Who are we developing for?" and may spend time meeting these customers, watching them do their work, and discussing the problems with the customers. This results in the one thing our manager was trained for decades to avoid: change.
Outsourcing, whether of IT or business processes, onshore or offshore, continues to raise expectations and pose challenges for private- and public-sector organizations alike. Despite the accumulated experience, learning has been painfully slow; there has been very mixed success and much conflicting advice. While it appears that organizations have a history of outsourcing experiences to draw on, the main problem is change. First-generation outsourcing clients often change what they outsource and how they outsource the second and third times around. Each time, they find themselves in a relatively new situation, having to learn anew. Furthermore, if their knowledgeable people leave and are not replaced, organizational learning may not occur sometimes until the fourth- or fifth-generation deal. Moreover, getting large-scale outsourcing wrong can seriously disable the business. On the upside, the potential payoffs from outsourcing are not just operational and cost-related. Indeed, the accumulated evidence demonstrates that outsourcing, properly planned, resourced, and accomplished, can deliver significant strategic advantage to firms and government agencies in every sector.
Since no company (or country) is taking the time to build quality and security into software products, I can only hope that the legal community turns its attention to the warrantless and liability-free contracts written by the software industry. These contracts are similar to "contracts of adhesion" that have been struck down in court for consumer goods. When the time comes that a major software vendor is effectively held liable for selling crappy software that exposes the buyer to catastrophic security risks, we will see major change. It won't take long for software companies to start doing what they should have done all along -- build quality products that can be warranted as fit for the purpose they were marketed to serve. We just need to hold software companies to the same liability standards that we expect from any other product. Let's hope that the time comes soon!
[Y]our partner advances a scheme that at first seems plain wrong. Failure. Won't work. Can't be done. You can adopt this view. You can argue about it, try to find an alternative or a compromise, but if you do that you won't be getting to anything new. Instead, reconceive. Think of the scheme not as wrong, but as something you don't know how to use. Yet. Instead of beating up your partner (or yourself) and lamenting a delay in your progress, you can embrace the new scheme as a spur to new effort, as a chance to extend and expand your skills. You can do this whether or not you finally end up using this scheme. Well, you almost certainly won't use it in the form it came in. You'll use it as it evolves when combined with the ideas you had, which themselves evolved when confronted with the "failure."
But is governance really that important? The question may seem ludicrous, but it is in fact more interesting than it first appears. First, there is growing support in management literature that suggests that in some situations simple heuristics are a better-suited instrument for providing direction and control than extensive planning and structured systems. Second, until we find a demonstrable link between governance efforts and practices with positive outcomes, the question should be allowed to linger. If implementing detailed governance mechanisms and structures is indeed useful to the organization, then the question becomes, what are these systems and how should they be structured to achieve a given set of expected outcomes? Finally, having identified the design and structure of effective IT governance architecture, we need to understand the process of implementing it to its full effect.
"IT Governance in 2009: A Thorn in IT's Side,"
Cutter Benchmark Review, Vol. 9, No. 9
Reductions in resources can have far-ranging effects. Examining resource utilization will expose opportunities for optimizing outdated business processes, requiring new systems, applications, and infrastructure. Especially at the manufacturing and operations levels, there are numerous opportunities for reducing resources. Some efforts, viewed alone in isolation, may not seem interesting or economically viable, but when viewed from an overall enterprise perspective can provide opportunities to leverage efforts across several initiatives or promote new revenues. For example, one way to reduce paper utilization is to provide employee information online in an employee portal. In a study done in the early 2000s, Bank of America calculated that it saved 100 tons of paper annually simply by putting their employee phone directory online Then, they were able to leverage the portal for other areas, such as online expense reporting.
"Going Green? EA to the Rescue!"
Enterprise Architecture E-Mail Advisor, 28 October 2009
All of us know the joy that one can experience from a good movie. Dramatic tension creates humor, intensity, excitement, and exhilaration. For a movie, that's a wonderful experience. In our work environment, that wonder is gone. We really don't want or need drama in our management work, and yet we encounter it on a ritual basis. Drama is borne on the backs of three primary sources: situations, others, and ourselves. In all three of these scenarios, we have some degree of control over that drama. We have the ability to exert that control, but in most situations, we don't. We should. By bringing down the level of drama, we reduce the possibility that small events will suddenly blossom into issues to be managed. And by bringing down the level of drama, we enable people to do their jobs more effectively without outside interference. Drama is a source of risk and, wonderfully, it's one that we can control.
Let's be real clear about the role that governance plays and its importance to the success of the business technology mission. If there is no governance -- or if it is weak -- then the company will suboptimize its business technology investments. If there's no governance at all, the suboptimization will be enormous. It results in overspending, poor service, and religious warfare among the technology deliverers and customers, among other problems. In fact, poor -- and especially no -- technology governance can threaten a company's survival. Extreme? Not at all. Some companies spend hundreds of millions and even billions of dollars on technology every year. Suboptimizing by 30%-50% will wreak havoc with every company's bottom line.
When an organization is considering outsourcing in any of its "shore" forms (offshore, nearshore, onshore), rumors will spread like wildfire, fueled by rampant speculation regarding motive. This is driven by the FUD factors (fear, uncertainty, and doubt) -- not only with your staff, but also with current suppliers and customers or even outside organizations such as government bodies, the media, and unions.
This isn't something that happens only at the beginning of an outsourcing initiative. All organizations need to communicate with a variety of people over the course of the outsourcing lifecycle. The degree of communication required often comes as a surprise to many organizations. Time after time, organizations had inappropriate planning and resources, sometimes requiring hiring an external public relations expert to manage communication. In many cases, communication takes a great deal more of the project's resources than was originally planned.
Today's software development environments have become amazingly complex, while modeling techniques have become more and more technical and arcane. Increasingly, we want users to look at either unintelligible (to them) models or agile prototypes that hide much of the business complexity we need them to help us unravel. To a degree, the inmates are in charge of the institution.
The only way out of this morass, I suspect, is to step back and rethink what we do today in the name of software engineering and to look at other more mature engineering disciplines for guidance.
One gets the sense that IT and business managers would benefit from some education and training in what IT does and what IT's value proposition really is, as delivered, to the organization. We sense this in the variations of the answers [to a recent Cutter Benchmark Review survey]; we know from personal experience that many business managers -- especially the senior ones -- do not know in detail exactly what value is delivered. Oh, they know it's important (we hope), but the details are sometimes lacking.
The creation of the Open Mashup Alliance (OMA), and particularly the Enterprise Mashup Markup Language (EMML), is a significant industry development. As I've said in the past, and as our research supports, I believe that the use of mashups in the enterprise is destined to increase considerably -- especially the use of data mashups for BI and decision support.
"Opening Up Enterprise Mashups"
Business Intelligence E-Mail Advisor, 13 October 2009
Many of our traditional architecture models, from enterprise to business, are out of step with the realities of the core/context strategy of the boardroom. These models need to shift gear to accommodate the thinking and techniques around the line of commoditization to become relevant to the hard-pressed, economically challenged world in which we live.
Core/context strategy is here to stay. However, while potential rewards in the form of cut costs are high, the risks can be devastating. Blind outsourcing is like playing a corporate game of Russian roulette. Much better techniques are required to expose assumptions and to clearly articulate the business proposition in terms of benefits and risks. Articulating the organization's line of commoditization, at software and business levels, can help.
Our two-decades-old World Wide Web architecture is long past due for an upgrade. During what we might call the "Web 1.0-2.0 epoch," demand for computing has grown across every enterprise, in every sector, around the globe. We continue to struggle to meet this demand using our traditional approaches to building and managing enterprise information systems. Mounting barriers of complexity and scalability continue to hinder business agility, increase costs, and constrain overall productivity. The Semantic Web (also often referred to as Web 3.0) is emerging as the prescribed solution, and it offers us a compelling architectural framework upon which to build next-generation Internet-ready applications.
"The Rise of the Semantic Enterprise"
Cutter IT Journal, Vol. 22, No. 9
Agilists who want wider and more significant impact from their agile initiatives need to persuade executives and managers to change their criteria for success from the old, cost, schedule, scope model, to one of value, quality, and constraints. This requires skill again in developing value models and convincing management of their validity, creating effective quality metrics that span multiple time frames (iteration, release, roadmap), and then understanding how traditional constraints (scope, schedule, cost) can be better measured and integrated into this agile triangle.
So in some important ways, agile development is as difficult as participating in multiple triathlons -- but not quite because you have a team doing it. Each member has his or her own triathlon.
"The Agile Triathlete Times Four"
Agile Product & ProjectE-Mail Advisor, 1 October 2009
Since I have a boat and am periodically in the habit of watching river and lake levels, especially in times of floods, I have been struck by the time-based relationship between rainfall, river levels, and lake levels. Rain falls first (or snow melts), and the inches of rain are counted in minutes or hours. Rivers surge days later, well after the cloudy weather has been replaced by sunshine. And lakes, last in the water chain, stay elevated for weeks after rivers have returned to normal. Since my boat is on a lake, my boat can't go back into the water until after the lakes have returned to normal. One year I missed a month of boating due to a few days of rain.
For this economy, the stock market is like the weather (rain or shine). The corporate quarterly earnings are like the rivers. And the jobs data (unemployment) is like the lakes. The lake isn't filling as fast as it was a few months ago and may actually be receding. If so, then it is time to start thinking about IT strategies for an up market, right?
Complex event processing (CEP) is an emerging technology that is increasingly garnishing more attention, especially since Microsoft announced plans to enter the market. CEP is getting a lot of attention because it holds the promise of enabling companies to increase operational efficiency by providing a means to identify and interpret the effect of seemingly unrelated events taking place across the organization and then notify the appropriate stakeholders with near zero latency. The goal is to allow stakeholders to take a proactive approach to managing threats and opportunities before they become too critical or slip away.
CEP is seen as a way to make implementing operational intelligence more practical, in effect, by collecting, filtering, and correlating events taking place across the organization with respective business processes in order to identify meaningful patterns. Single events that relate to each other are correlated to form a complete process, applying rules and threshold values. In short, CEP monitors individual events to check that they are behaving as expected in order to achieve the intended result, such as the successful delivery of a product or service. CEP systems also employ dashboards and alerts to notify appropriate staff of any deviation from the expected process sequence so they can intervene and guide the process to the desired result. CEP can also apply rules to launch other processes in response to a detected deviation or trend.
The world of business has been discussing for a few decades the pros and cons of top-down versus bottom-up and planned-versus-emergent strategy. The debate focuses on the limits of human knowledge and the ability for any one person or group to collect good information across the firm and the environment and act fast enough. This is an old and ongoing debate. Except for one wrinkle: information technology, it turns out, may be changing the game. Firms can perhaps have the best of both: some measure of emergent and bottom-up design and the ability to sense and share data from many places all at once. Bottom-up design doesn't necessarily mean fragmented IT.
Even the military, taking advantage of advances in networking that enable instant communications across the globe, is finding ways to replace top-down modes of communication that always relied on large staffs at the top to sift through data. Now, with point-to-point communication, the top brass, which is now just a critical point in the node, can weigh in, instantly, to an unfolding scene. Top, bottom, and sides are all hooked up in a collaborative network. Hierarchy smierarchy.
Many of our business processes -- operating over the Internet or otherwise -- remain wedded to a production-line mindset that is stuck in the world of the 1980s. A well-planned business process management (BPM) and service-oriented architecture (SOA) strategy needs to encourage the use of services as a tool to improve processes and solve specific business problems. At the same time, organizational politics and the investments in BPM and SOA already made mean that we need to tread carefully.
Fear is a tool. It can motivate the overweight to diet. It can motivate the lovelorn to try online dating. It can motivate management to hire consultants. It can motivate team members to work overtime. And yet, it has the potential to be overused and abused. If we are driven to a state of fear too frequently, there is the potential for us to become inured to the notion that harm may actually befall us or that the fear is well founded.
Look at the reasoning behind major business decisions in the past year. GM went to the government for fear that they would ultimately be bankrupt and go out of business. Ford did not pursue government funding for fear that bureaucrats in Washington would ultimately control them. Both companies faced fears rooted in similar risks, but responded to them very differently.
The notion of fear as a tool can be seen in virtually every walk of life and in practically every organization. The challenge is to find ways to use fear in a healthy way, rather than as a potentially damaging influence. The great damage that fear does when used in an abusive or painful manner is that it creates an environment where the avoidance of the fearful element becomes the overriding concern, rather than the conduct of the mission at hand.
by Rebecca Herold
So how are you going to get all the key business leaders interested in making sure information security controls and privacy protections are in place, in each of their locations, and incorporated into their day-to-day business practices? It can be challenging. You will not successfully safeguard information or protect privacy unless all leaders throughout the organization, in all locations, understand the importance of daily security activities and are on board with your security and privacy initiatives. The challenges increase as the line between employee personal activities and business activities blur. Organizations must be prepared, have well-written and effectively enforced policies, and provide ongoing awareness communications if they hope to have a strong information security and privacy program that can protect the business from all sorts of unfortunate situations.
by Jens Coldewey
An agile organization is an organization whose value system complies with the Agile Manifesto: an organization that values individuals and interactions over processes and tools, that values working software over comprehensive documentation, that values customer collaboration over contract negotiation, and that values responding to change over following a plan. This value system should be reflected in all parts of the organization, in the development team as well as in the sales team, in controlling and in every decision of the board.
"Has Agile Crossed the Chasm?"
Agile Product & Project Management E-Mail Advisor, 10 September 2009
by David N. Rasmussen
There are two considerations in defining requirements. The first is to determine what the market wants; the second is to define what is possible and practical for the product to provide. These are not always the same. The market, or the customer, may want features, performance, or services that may not be technically possible or affordable. There may be viable alternatives to satisfy the customer's requirements that could be considered. However, this won't be possible if the customer (market) requirements document is not produced first, representing the desires of those who need the product. Once completed and approved, it represents the definition of what the users want.
Separately, a product requirements document represents what is practical for the developer to produce. This is where alternatives are considered to meet functional, performance, and service needs and the optimal features selected for development. The product team must ensure that all functional areas of work are considered in defining these requirements before development work begins.
by Paul Allen
One of the myths that we need to explode up front is that by following an agile development approach, you will automatically get agile software. This is a bit like saying, "I bought my ticket, so I can see the show." Although the creators of the Agile Manifesto provide us with some great principles,3 I think it's fair to say that they're primarily about achieving good project practice. OK, "working software is the primary measure of progress," but the overall advice embodied in this and other agile principles is very much geared toward projects, not products, and toward behavior, not design.
"How to Measure Software Agility"
Enterprise Architecture Executive Update, Vol. 12, No. 16
by Robert N. Charette
For project managers, though, I think project professionalism is a bit more complex. For one, it includes being absolutely honest about the project’s probability of success and the ability (and stomach) to quickly terminate a “losing” program when it is no longer technically or financially feasible. To do otherwise serves merely to increase the opportunity costs incurred by the organization -- costs (i.e., resources) that could be better applied to better use elsewhere.
Unlike major league baseball, where you have to play out the 162-game season no matter what, projects don’t need to keep playing when the “season” is lost.
by Bob Fischer
Two primary paths lead a company to agile. The first is a recognized business issue -- the inability to get products to market fast enough -- and agile is proposed as a solution. On the second path, you learn about agile, like what you hear, and propose to use it. No matter the reason, you'll need to find a common vision that people in the organization can get behind. Agile requires organizational changes, such as dedicated team members, and often money for training, coaching, and tools. If your organization has a clear vision of why it is trying agile, it is far more likely to support the inevitable changes that the approach will bring about. If it isn't, you are likely to get resistance that will slow down your first agile projects. Arriving at this vision will require time: from you, from your organization's leadership group, and from the thought leaders across the organization. In the end, it will be worth it.
by Steve Andriole
We should appreciate how the economic crisis is changing "normal" technology adoption processes and prepare for the earlier adoption of emerging technologies, especially since the technologies offer significant cost savings.
by Vince Kellen
But how do you decide which information is properly dense and which isn't? How can an IT leader divine from which garbage pile of overly dense information will spring the next great innovation?
Because of the impracticality of rationing data and the exponential growth in information density, some of it fueling beneficial individual learning and team performance, I see no constraints on the demand for capacity.
Of course, this will bode well for hardware manufacturers, resellers, and integrators. But will it also bode well for organizations that have larger piles of information manure to dig through to find a pony?
Some biologists have pointed out that the biomass of insects far outweighs that of humans. I wonder when (or if) the virtual biomass of data will outweigh all life forms.
by Curt Hall
My position all along has been that Web 2.0 (applied in the enterprise) is actually just a new form of collaboration model, the purpose of which is to improve business performance via more open and richer communication and to facilitate the widespread dissemination of ideas and knowledge throughout -- and, wherever applicable, beyond -- the organization. In other words, the goal of Web 2.0 is basically to "flatten out" the organization by opening up the decision input/making processes to the extent that it leads to increased participation by a broader coalition of stakeholders. And this, in turn, will spark more in-depth brainstorming sessions, which, it is hoped, should lead to increased innovation. I say "it is hoped" because although Web 2.0 can be a "game changer," there's no guarantee that the organization implementing Web 2.0 is going to experience success any more than an organization is guaranteed of major success from implementing any other information technology. (Thus, there's nothing mystical or magical about it.) I happen to believe that there's a good chance of reaping benefits, but still there are no guarantees that a company is going to succeed just because a particular technology has been utilized.
"Web 2.0: Yawn?"
Business Intelligence E-Mail Advisor, 1 September 2009
by Ken Orr
I suggest that we stop for a second, take a deep breath, and think about this whole interconnected, Internet-based world thing over again. I know that we can't go back and redo the whole thing (the security design for the Internet), but it seems to me that we can step back and identify the most important factors to any modern, developed economy, think about securing those elements, and then move outward to consider the rest of the network.
For starters, we need to deal with the electrical and telecommunications networks. Nothing in the modern world works without electricity, and electricity doesn't work without telecommunications. In the bad old days of monopoly power, utilities had the luxury of planning way out into the future and to worry about very rare events; the job of utility planners and think tanks such as Bell Labs was to think the unthinkable. In the past 30 years, in the age of deregulation, we have encouraged every organization to think only about short-term economic gain and forget about what could go wrong.
by Sara Cullen
Knowing what you want, understanding what is practical, specifying how you want to go about it, and having performance measures reflecting the achievement of your goals will start you off in the right direction. These are only the initial steps [in an outsourcing contract], however. Making sure the other parts of the contract do not conflict with innovation (such as restricting ownership of intellectual property solely to the client) and putting in place the right people and practices to see it through from concept generation to benefit realization are also imperative. But these first few preliminary steps will get you thinking pragmatically, rather than having abstract expectations that are simply impossible to achieve.
by Paul Allen
Architects need to stop acting like an IT police force that stamps the efforts of teams as "compliant" or "noncompliant" and start acting in a proactive fashion, nurturing teams with pragmatic advice. Equally, agile team members need to take the blinders off and realize that they are part of a much bigger picture. Defensive postures on both sides need to be turned into positive ones.
Many will point out that, hey, service architects do bring value to the agile table by establishing a solid SOA platform through proof-of-concepts that enable agile teams with infrastructure services. OK, so some organizations do that! However, this must be seen as only the start of a collaborative relationship. Service architects need to build on early successes by working with agile teams to harvest good common design patterns for fertilization across agile teams. The new economy will have it no other way.
by Steve Andriole
One of the major strengths of cloud computing is the freedom it gives companies to think strategically -- not tactically -- about how they want to leverage technology. Instead of worrying about network latency and server maintenance, business technology professionals can focus on innovation, sales, and marketing, among other revenue-generating activities (within and beyond the cloud). Another strength is flexibility. Picking from a menu is easier than designing one -- and then delivering the food. Scalability is often just a phone call or e-mail message away.
Freedom from software maintenance, security assessment and control, software version control, viruses, and other operational headaches is a byproduct of cloud computing. But nothing is perfect -- far from it. Remember how long it took the consultancies to install ERP applications that actually worked? Cloud computing, too, will evolve over time. Companies should adopt a flexible approach to the piloting of cloud computing services. The performance data they collect along the way will determine the future of this technology delivery model.
"Entering the Cloud: Phased Adoption to Computing Nirvana"
Cutter IT Journal, Vol. 22, No. 6/7
by Jim Highsmith
There is some concern in the agile community that with big companies wanting to become "agile," that the essence of becoming or being agile will be watered down -- that the true test of agility, having an agile mindset based on agile values expressed in the Agile Manifesto and Declaration of Interdependence, is getting lost. With anything like the agile movement, this dilution is inevitable, but the important question is whether agile transitions are benefiting companies, and for the most part I think they are.
Some people view agile as a software development capability, and they get a certain level of benefit. Others, like me, believe that agility is a strategic business capability that can generate significantly higher levels of benefit. However, I wouldn't deride the efforts aimed at the former, because there would be benefits. In some businesses, such as an independent software vendor (ISV), the strategic benefits of agile development could be substantial, while in another business, software development will not be strategic. In the latter, trying to knock down cultural barriers to more comprehensive agile practices will probably not be worth the effort.
Impediment or barrier? This question will be at the heart of any agile transition, the answer will be different in every country and every company, and just posing the question will assist in coming up with the right strategy for agile transitions.
by San Murugesan
Cloud computing, driven by economic imperatives and the promise of flexibility and convenience, will remain an area of keen interest for years to come. If the current momentum in cloud computing continues, both individuals and enterprises will be computing in one or more clouds, public or private, in a major way within the next five years. Though there are major stumbling blocks for enterprises moving their applications into the clouds -- such as reliability, performance, bandwidth requirements, trust, and security issues -- these barriers are being gradually lowered or removed. Government regulations and other compliance requirements, which often lag behind market developments and demand, need to be addressed swiftly.
It's time to give cloud computing serious and favorable consideration. If we join the cloud revolution now, clouds -- in one form or other -- can help reshape the IT landscape for the benefit of all, whether individuals or businesses of all sizes and shapes. Widespread adoption of cloud computing will also help close the prevailing digital (information) divide, particularly in underdeveloped and developing economies. It might even help save our planet by providing a greener computing environment.
"Cloud Computing: IT's Day in the Sun?"
Cutter IT Journal, Vol. 22, No. 6/7
by Bob Benson and Tom Bugnitz
We've previously written about the difficulty of engaging BU management in governance (see "Getting Management Involvement in IT Governance," 3 December 2008). The short of it: they may not see the benefit to them or their business to spend the time and energy to get involved.
This is a problem, since there are so many areas that business management should be engaged. We suggest that you determine the degree of involvement and set a course for improving engagement. You should consider:
- The degree to which IT governance management practices (the list of activities above) are in fact applied in your organization
- The degree to which these IT governance management practices are effective. By "effective" we mean
a. The degree to which business managers actually participate
b. The degree to which the practices add value to the business (note: for companies, this is the bottom-line impact of IT; for government and other nonprofits, this is the impact on mission performance)
by Ken Orr
The modern organization runs on networks of applications and networks of databases. While it might have been true 30 or 40 years ago that one could think of a large organization as a set of more or less independent applications and databases, that day is long gone. To understand how a large, technology-enabled organization works today, you have to think of networks of applications/databases and the dataflow between major processes-- what James Martin and Ralph Whittle call "value streams."
Thinking of EA in terms of cells leads people to think of EA in static terms. Thinking about EA in static terms is wrong, and it can be disastrous because it can lead management to think that it can replace a critical system or database without considering all of the things that are connected to it. Modern systems are not interfaced; they metastasize!
Thinking of EA in terms of nodes, networks, and value streams is far more productive and useful.
"Avoid the Static: Think of Nodes, Not Cells"
Enterprise Architecture E-Mail Advisor, 29 July 2009
by Carl Pritchard
In many cases, the protective measures we install are obsolete not long after they're in place. So we eventually need to ask what steps and what options are at our disposal for the unwanted guests who find their ways into our systems. Obviously, detection is a crucial consideration in making organizational systems less desirable to attackers. But there are other things that make the risk less worth taking. Take a lesson from the puffer fish: it's slow and easy to attack. So, why isn't it extinct? When it's attacked, it gives the attacker more than it bargained for. For one, it puffs itself into a small balloon, potentially choking its attacker. For two, the balloon is covered with tiny poison spikes, which can quickly claim the life of its unwary assailant.
Why the digression into the life and times of puffer fish? Because that should be the model for our next consideration. We should make our organizational vulnerabilities as completely poisonous and undesirable as possible to those who would breach our systems. When someone gets into our systems (physical or virtual), he or she should find the information desired in formats that cannot be managed. The data sought should be incapable of being "swallowed." And if the intruder is able to get past our systems and encryption, we should leverage lessons from the hackers with the occasional tempting Trojan or worm of our own. (Note for the noncyberwary: the same principles apply to physical files as well. A paper record of credit card data, for example, on a card that we specifically file for security purposes, can serve as our own Trojan horse into the thieves' lair.)
by Bob Fischer
You'll likely decide to make the transition to agile if there is a compelling business objective for doing so. Reasons may include decreased time to market, higher quality, increased employee engagement, better use of each dollar invested, or greater focus on delivering what your customers need.
Once you've decided to make the transition, you'll want it to be smooth and effective. Having someone specifically responsible for that transition -- the agile evangelist -- will help ensure that outcome. The person in this role must be both a master of change management and someone who understands the specific challenges inherent in moving an organization to agile.
by Vince Kellen
As always, it turns out that the difference between what everyone heard at the demos, the sales meetings, and the planning sessions and the cruel reality of the situation is not small. If you get a chance to talk to teams that selected and implemented complex IT solutions years after the implementation, you will find that critical knowledge was not available to them, for which the consequence was significant. However, the cost of correct reimplementation now will appear to exceed the benefit of hard-earned and often painful adoption of the tool across the enterprise. Imperfect status quo reigns. Corporate citizens have had a sword thrust in their hands and have learned to wield it after much grinding of teeth and wailing. In some cases, this difficult break-in period even appears to deepen user attachment to what was initially a very imperfect sword but is now one to which human minds and cultures have slowly adapted. I presume that 10 years post implementation, the next generation of implementers of the replacement for the sword will have to pry the old one out of their cold dead hands. The cycle repeats ad nauseam.
"Lord of Their Ring: One to Rule Them All"
Business-IT Strategies E-Mail Advisor, 15 July 2009
by Paul Allen
Organizations have traditionally organized IT along reductionist lines leading to a compartmentalization of IT into development, operations, and more. More broadly, the IT industry itself is full of niche comfort zones. One of the unfortunate consequences of the niche mentality is that the execution management of software is treated as an entirely separate subject from such topics as analysis, design, and development. While separation of concerns is necessary for specialization and discipline, it becomes unhealthy when important interconnections and relationships between domains of interest are ignored -- when separation leads to divorce!
In our present context, this trend surfaces in the separation of service-oriented architecture (SOA) from both overall operational management of IT services (in a general sense) and specific execution management of software services. These divisions are deeply embedded in our IT culture. If we want this situation to change, then our IT culture -- the unwritten rules of the game -- needs to change.
Cutter Consortium helps companies leverage IT for competitive advantage and business success through its comprehensive range of consulting, training and content, provided by the leading expert practitioners in business and IT.
Learn more »
