E-MailArchived Quotes of the Day
by John Berry
With an almost evangelical fervor surrounding it, the steady flow of rhetoric concerning alignment of IT with the business side of the organization assumes that if the IT organization pushes for it, business units will enthusiastically embrace it. Often this is not true, and IT managers must prepare for those occasions when the technology organization is truly ready to transform how it interacts with business units when everyone else isn't.
Never assume that others recognize the value of anything without specifically pointing out that value. (Just ask any manager undeservedly passed over for a promotion or a product manager whose true innovative product sank like stone for poor marketing execution.) Alignment is pitched to IT managers constantly and relentlessly as an assumed good, like justice and mercy. Just because IT becomes a true believer doesn't necessarily translate into automatic acceptance with others in the organization, as disappointing a fact as that is. Alignment means change and no one likes change. You'll have to win over the skeptics, which takes planning.
by Alfredo Funes Cervantes
Without doubt, contractual issues are the keys to implementing an outsourcing solution. Ideally, no one has to initiate penalties for compliance failures. It is better to get a costly yet effective service without the need to assess penalty charges due to failures than it is to have an enormous penalty because of a failure. Nevertheless, a good contract should raise both the provider's and client's consciousness about everyone's obligations as well as the penalties in case of failures. Besides covering the customer-provider relationship, the contract should be as accurate as possible in setting up responsibilities.
by Curt Hall
Search is having a major influence on BI, data retrieval, and analysis in general. Although the technology is still developing, the combination of BI and search is important because it promises to provide nontechnical business users (i.e., BI consumers) with easy access to, and the ability to analyze, both structured and unstructured information.
Initially, most organizations will use search to augment their more traditional BI and data warehousing capabilities as they seek to provide easy access to both structured and unstructured information. Consequently, I recommend that you view BI search as supplemental to your organization's overall BI strategy. I also think that the BI vendors' BI search offerings are going to prove very appealing to companies because they will be seeking a relatively straightforward way to add BI search their existing BI platform investments.
Over time, as more organizations seek to distribute BI functionality to increasing numbers and classes of BI consumers, search-powered BI techniques will begin to come into their own. And eventually, BI search is going to have major implications for organizations because it will allow them to provide employees, partners, and customers with true self-service BI capabilities that require little or no training and assistance from IT. This will also serve the corporate goal of distributing BI functionality to increasing numbers and classes of BI consumers.
by Steve Andriole
I say "tomahtos," and you say "tomaytos"; I say "ant," and you say "ont." The world is composed of very different people with different technology acquisition, deployment, and support biases. Some companies will never enter the cloud; many will enter it only after just about everyone thoroughly tests the air; and some will actually enter it today. My sense is that core competency is driving the decision whether or not to enter. Companies that want to eventually get completely out of the operational technology business will enter the cloud as early as possible; companies that cling to operational (and strategic) technology as part of their core competency will avoid the cloud.
The larger questions are about the Internet itself and, ultimately, what it can and cannot do. There are some serious issues around the Internet's architecture. Some believe it's on the verge of collapse, while others believe that it's only a few thousand servers away from stability. The US has not made the Internet part of the national infrastructure. Depending on what you think about government efficiency, you may want to keep the government as far away as possible from the policies and technologies of the Internet and the World Wide Web. But just as wireless device adoption was gated by the speed of wireless networks, so too will the adoption of cloud computing be driven by the Internet's overall stability, reliability, scalability, and security. Its capabilities must be assured by someone, or lots of potential cloud computers will stay away.
by Christine Davis
There is this renewed energy around innovation over the last couple of years primarily driven by the diminishing returns on the continual cost-cutting efforts that have been used to meet financial goals, such as profitability. Businesses are quickly trying to increase revenue to cover the rising cost of operations in all kinds of innovative ways. Organizations are involving their customers and suppliers in their innovation process and searching for ideas that are not internally generated. Historically companies have been very protective regarding their internal R&D and their future product and service strategies, treating most everything in a very proprietary manner including being very cautious about who they involve in the process. Technology has enabled businesses to be inclusive in this process, specifically through the ability to network via the Internet and all the forums that medium has provided. In fact, businesses receive feedback whether they want to hear it or not through blogs and online chat rooms. It is very difficult for any company to totally isolate itself in today's world. There is a trend developing toward open innovation where all the company resources, employees, customers, suppliers, and critics are applied to create new products and services, but the "open kimono" approach comes with some risks and challenges.
"Aligning Innovation and Strategy"
Cutter Benchmark Review, Vol. 8, No. 8
by Mike Rosen
As enterprise architects, we often face tasks aligning business and IT. One approach to this alignment is characterized by the Parker-Benson Square Wheel. It tells us that there are two sides to this equation. IT aligns technology with the business by responding to changes in business strategy and operations. This is the traditional role of IT. But the square wheel also tells us that IT, and architecture in particular, has the ability to align the business with new opportunities based on changes in technology. Another way we often look at this is by examining IT's role in cutting costs (responsive), as compared with its role in adding value or revenue (proactive). As architects, we're always looking for those opportunities to be proactive, to add value, and to present new opportunities to the business. Today, collaborative applications present such an opportunity.
Consumer applications and Web 2.0 technologies are setting new expectations of users. People are now used to the sophisticated user experiences offered by sites such as Google maps and by the extensive and up-to-date information offered by such sites as Wikipedia. More and more people, especially younger users, are expecting the community capabilities offered by sites such as Facebook. Few of these capabilities have made their way into enterprise applications, however, and in the few cases where some of them have appeared, there has not be an integrated approach to combining these new capabilities, nor an architectural approach that fits them into the overall, end-to-end applications of the enterprise.
"Collaboration: What Does It Mean? Part I"
Enterprise Architecture E-Mail Advisor, 3 September 2008
by Carl Pritchard
Becoming agile means accepting uncertainty about the future as a way of dealing with the future. Any project development effort should be a balance between anticipation (planning based on what we know now) and adaptation (responding to what we learn over time). The critical management decisions are dealing with the balance point -- how much time do we spend investigating requirements, technology, and so on, in the beginning of a project versus actually developing product features (working software) and adjusting/adapting to new information as the project unfolds.
Traditional teams attempt to drive out uncertainty by planning and analysis. Agile teams tend to drive out uncertainty by developing working software in small increments and then adjusting. However, traditional teams often think they have mitigated much of the uncertainty, when in fact a high degree of uncertainty remains in the project. They "project" certainty in plans, estimates, and presentations, and upper management becomes comfortable that the project is "on track." When, late in the project, as the software is actually running (or not), the uncertainties begin wreaking havoc on the project, the team becomes less certain about real progress, and major cost overruns and schedule slips are announced.
Agile teams, on the other hand, often project uncertainty early in the project and become more certain later in the project. Agile project managers are often hard pressed to defend their uncertainty because upper managers are in the "you can be right, and you can be wrong, but don't be uncertain" mindset. Dealing positively with uncertainty, being willing to accept that certain things are unknown and unknowable (for now) are big parts of learning to be an agile manager.
by Verna Allee
Value network analysis (VNA) does not make other management tools obsolete. It does, however, fill the analytical and managerial gap between other business tools. It makes possible a new generation of business practice designed to support productivity growth and innovation.
Focusing on people as the "true agents" of value creation provides a new perspective on how to initiate value. People move to center stage in the business model. Instead of being considered interchangeable cogs in the wheel of industry, they become the means of production for value itself. By integrating financial and intangible asset management with a deep appreciation of these very human dynamics, value network analysis provides a way to truly model how a knowledge-based enterprise creates value.
"Value Network Updates"
Business Intelligence Executive Update, Vol. 8, No. 14
by Vince Kellen
We may be seeing the emergence of legal IT and business process outsourcing as a category to rival HR outsourcing. Of course, much of this depends on how law will be interpreted over time. But if the past is any indication of the future, I have the following prediction: in about 12-15 years, it will be more cost efficient to store all prior and current versions of all information of any kind in one central environment.
If this turns out to be true, it may contribute to the ongoing increase of outsourcing data management all together. Other factors include driving data center outsourcing, such as the facilities and energy costs that will require more scale than most companies can build or manage on their own, or the rise of virtualization, which is making it easier for hosting centers to manage more complexity. Desktop virtualization will also simplify the e-discovery problem as the central data can be managed more easily. In addition, continued adoption of Web services and service-oriented architecture (SOA) may help reduce the cost of managing the data information gap, which will push more strategic systems into hosted data centers.
The only question I have nagging in my head is how much the legal tail will be wagging the IT outsourcing dog. Only time will tell.
by Gabriele Piccoli
IT has always been a master of doing more with less. A slowing macroeconomic environment is, believe it or not, a great time to be in IT -- for virtualization and data center consolidation, and for customer segmentation and business intelligence projects.... Strategically astute companies know that an economic dip is the best time to make innovative IT investments that can create differentiation. If those investments are deployed when competitors are retrenching, they can grow the bottom line.
"The Intricacy of IT Budgeting: Is the Glass Half Full?"
Cutter Benchmark Review, Vol. 8, No. 7
by Ken Orr
Most IT advances are the response to a major problem, some of them brought on by external conditions, such as the energy shortage, some brought on by technological advances. Advances in computers and communications technologies have made organizations much more advanced, but not necessarily more adaptive or flexible. Today, it is not enough to concentrate just on specific application systems "done for" and "controlled by" specific departments or organizational units; organizations must focus on how those systems are connected (internally and externally) and increasingly use common data (internally and externally). Enterprise architecture is the only place in the organization where it is possible to get a big enough view of the enterprise to be able to understand those connections.
The future of the modern enterprise depends not just upon its people and organizational structure or even its capital investment of organizational knowledge; the future of the modern enterprise depends on how well we understand, plan, execute, and maintain our IT framework -- i.e., our enterprise architecture. Many top managers are uncomfortable with dealing with these kinds of issues and so are many CIOs and CTOs, but the problems are real and ignoring them will not make them go away. Like neurologists and psychologists, we need new tools (as well as new theories and methodologies) to understand what actually exists.
by William A. Zucker
Certain things, such as death and taxes, are inevitable. Conflict is one of them. If you know it is coming, even if unlikely, shouldn't it be part of the risk management plan? We plan for other contingencies; why not conflict?
We look at conflict as a distraction, and with dread. It is never part of the program because our first reaction to it is flight or avoidance. Conflict is a prospective budget buster or project stopper, and because it is not part of the program, we do not actively plan for it. We leave it to others. Mostly, we leave it to lawyers.
Is this truly planning to mitigate conflict? The lawyers, of course, have their forms for it. They treat it as boilerplate. That is part of the problem. It is really no plan at all -- especially if there is an organizational preference for litigation, the prospect of conflict may not be addressed. Does that make sense? Usually such preferences for a judicial resolution are driven by the organization that superficially expresses that it wants to be sure the law has been properly applied. Given that the number of business cases that actually go to trial in the federal courts has dropped to less than 2%, the law is rarely being applied. In fact, litigation in federal courts (or in state courts, for that matter) is an expensive, time-consuming process. This is an approach to conflict, but it is really on the scale with childhood bullies. It is not problem solving. To the contrary, such an approach usually reflects poor planning or companies that, because they are bigger, really have adopted the strategy of using their size and deeper pockets to force a bargain. Faced with the expense of litigation, a deal for their target is the lesser of two evils.
by Sebastian Konkol
In thinking about the role of IT organizations in shaping the IS environment, one can see that the focus is moving toward big IT-enabled endeavors, which means providing the business with new support capabilities through projects being rolled out. However, the IT organization often struggles to balance the relatively small number of big projects aimed at rolling out a new IT system with the relatively big number of small "projects" aimed at the introduction of various small changes in the existing IT systems environment. With each scale of development effort -- whether it is a big project or change request -- some limitations are being introduced that are rooted in the necessity to compromise software flexibility or architectural purity in favor of constraints like time allowed for the work to be done or available funding. The smaller the development effort, the more likely it is that external constraints will result in the software limitations with respect to initial requirements. In theory, such compromises should be registered and communicated, but the practice is quite different.
by John Berry
Most managers may believe that the alignment imperative between the investment and corporate goals is the first criteria any prioritization technique must address. Happily, the nature of ROI analysis with its discovery of benefits expressed in KPIs satisfies this criteria. It should not be difficult for managers, once the data-driven details of an ROI analysis are in front of them, to determine the alignment possibilities of that technology under scrutiny. Once the alignment possibilities are understood, then managers can think about IT investment in the context of company strengths and in the context of the fundamental and causal drivers of financial success. Conceiving of technology in terms of value rather than functionality is a profound mental shift for some organizations, and long overdue.
by Alfredo Funes Cervantes
Beyond all doubt, the trend to outsource functions developed inside an enterprise or a government agency is at its peak. This phenomenon is not limited to IT; it's under consideration in several areas of an organization. Although outsourcing is a very appealing concept, it is essential for a company to be properly prepared for this kind of change.
In both the public and private sectors, it is common to find operating plans that have met their needs by using internal resources. A framework of processes, assets, and human beings has been built over the years to keep the business afloat. This framework is now threatened by a model that suggests operations be carried out externally while keeping the strategy, the negotiation, and oversight inhouse.
Like any management initiative, you can't grade this trend good or bad. It is not a black-or-white matter. You must be aware of the shades of color created by opportunities, advantages, risks, costs, organizational culture, idiosyncrasies, and provider quality. In other words, to outline the optimal strategy, you need a preliminary analysis to weigh costs and benefits. Once defined, that strategy may succeed or fail according to the way you implement it.
by Steve Andriole
Technology organizations are both advancing and delaying the deployment of Web 2.0 technologies. Some organizations absolutely require that Web 2.0 technologies, like all enterprise technologies, be governed by the same processes that govern the acquisition, deployment, and support of all technologies. Other organizations are loosening their grips somewhat, primarily because it's virtually impossible to prevent the creation of a wiki or a blog by a business unit or project team. Clearly, some new governance is required to optimize the use of Web 2.0 tools.
We're also seeing a predictable technology adoption process. Web 2.0 technologies are not unlike any new technology basket that companies need to assess. There have certainly been early adopters who as early as 2004 were deploying some of the tools to initially improve communication and collaboration. Some companies have been early adopters of R&D crowdsourcing, while others have waited until 2007 or 2008 to pilot Web 2.0 technologies.
There's a clear hierarchy of Web 2.0 tools. All of the companies interviewed have deployed wikis and blogs. Many have deployed RSS filters and podcasts; fewer have deployed social networks, mashups, and folksonomies; even fewer have invested in crowdsourcing and virtual worlds. There's a deployment momentum at work, as there often is when new technologies appear. Momentum breeds momentum, and we can expect wikis, blogs, podcasts, and RSS filters to gain momentum as the other Web 2.0 technologies lag. This means that the models for exploiting these early adopted technologies will grow faster, wider, and deeper than, for example, optimization models for virtual worlds. The key here is what the vendors offer as integrated application/deployment/support packages.
by Ken Orr
At base, computer-based applications that exploit parallel processing are not much different from assembly lines. Individual modules do specific tasks and hand off their results. What makes the whole assembly-line design approach work well in a parallel processing environment is the model that makes it possible for each module to be designed, developed, and tested independent of all the others and then plugged together to be synchronized. In programming parallel/distributed processes, the modules need to be elegantly simple; for here more than anywhere, complexity really doesn't scale.
by Vince Kellen
With so much talk about the management of innovation, we have lost sight of something more important: innovation in management. When innovative products wow us, innovators of those products receive our praise and adulation. It is a time-honored tradition as old as civilization itself. After all, every age will have its Michelangelo. However, innovation in management, while usually unseen, is much more important than innovation in products. One could argue that behind each great innovative product lies an innovative approach to management. Companies will find it hard to create innovative products using outdated management approaches.
So why don't companies look deeper at their approaches to management and find innovative ways of organizing things?
by John Tibbetts
User interface speed, style, and usability took a big hit when applications moved onto the Web. With AJAX leading the way, Web 2.0 has gradually rebuilt front-end capabilities to something approaching, and probably soon surpassing, what users were seeing on their workstations 10 years ago.
Rich Internet applications (RIAs) will certainly be the next decade's powerhouse, and enterprises that want a powerful Web presence should be taking steps toward adopting this new technology. RIA development platforms make the task quite manageable. Choose one or two, invest in a significant pilot project, and give both your developers and your users hands-on experience with RIA-enabled applications. I predict that both will appreciate the richer, cleaner, more intuitive, and more productive environment.
"RIAs: Uis, Platforms, and Architecture"
Enterprise Architecture Executive Report, Vol. 11, No. 7
by Jim Highsmith
Given the problems of getting the end customer involved, many organizations give up and let the product team take over nearly all customer interaction responsibilities. Herein lies potential disaster. Over time, the product team itself becomes dissociated from the real customer and begins to think they know what the customer wants. Development teams have been down this road before, and know that trying to "be" the customer seldom works. No team external to the customer has the depth of understanding of the customer's business. For short periods, the product team may be on track, but lack of frequent customer feedback usually leads to problems -- in particular with complex, state-of-the-art applications.
by Steve Andriole
The relationship between business and technology has never been more center stage than it is today. Technologists must learn more about the business than ever before; business managers and executives need to understand technology's potential. Technologists need to speak the language of business and avoid nerdy references to bits, bytes, and lights. Projects need to be the result of rigorous business case analysis and then managed predictably and professionally. Standards, architecture, and planning also need to be improved to deliver more value to the business.
So what does all this have to do with the reorganization of IT? A lot. The world is shifting away from computing and communications infrastructure and even mainstream business applications toward the business value of technology managed by a set of professionals with relatively new skills.
The center of gravity in this new world is the business technology management office (BTMO), which owns all project demand, prioritization, and execution management. While the actual work continues to occur in the infrastructure and applications groups, the BTMO is the face of technology to the business.
by Sara Cullen
Despite over a decade of research in IT outsourcing (ITO), no single model of ITO success has emerged from the literature. Each study regarding success, and advice on how to achieve it, is dependent on how the researcher defined "success," "outcomes," and "benefits." These terms are often used interchangeably, though their definitions vary considerably. Not surprisingly, different perceptions of what constitutes outsourcing success have yielded conflicting conclusions on the degree to which outsourcing practices have been successful.
One of the key issues concerning an accepted success construct is whether a certain outcome, such as cost savings, is desirable and therefore applicable to every outsourcing initiative. Alternatively, perhaps success is so idiosyncratic that one must judge success against each organization's own different criteria, rather than presupposed criteria. The predominate construct in previous ITO research is the former -- the definition of success is fixed and the research is designed to see whether it was achieved or not (regardless of what the organizations had set out to achieve).
by Ken Orr
Despite comments to the contrary, most computing languages -- both traditional and modern ones -- are fundamentally designed around a sequential, parallel model. I believe that coming up with new languages that make developing parallel programming as common as traditional serial programming won't happen until we get people to think, analyze, and design differently. Right now, for example, we break programs into a series of sequential steps to solve complex problems. Even the most commonly used compilers work this way: parse, analyze, design, and generate. It is hard for people to think in a parallel fashion.
As it turns out, I think that parallel software in mainstream computing is a big new area but it is not going to be an easy transition for current developers. The key to parallel design, I have found, is thinking backward.
by Mike Rosen
With SOA, we can implement enterprise-wide customer service that manages the shared customer information (like addresses) for all systems and so it only needs to be changed once. Alternatively, we can have a single inventory service used by all order management processes where they would get consistent results about availability. This is something that the business sponsors understand, and are often more willing to pay for than the promise of reduced costs and reuse. Personally, I never try to sell reuse. First, it's not a business value; it's a technical detail. Second, it's difficult to achieve. Third, as an industry, software has a bleak record of delivering reuse to the enterprise.
"Will SOA Survive Without Reuse?"
Enterprise Architecture E-Mail Advisor, 16 July 2008
by Vince Kellen
Clearly, ... the [Enterprise Software (ES)] market is in transition and ... this transition involves principally the rise of SOA and the adoption of SaaS and E 2.0 technologies. Interestingly, these three technologies may be contributing additional complexity to the ES soup. Large firms can add architectural complexity and perhaps spur unintended growth of redundant business processes through increased adoption of SaaS and E 2.0, which SOA enables. This may undermine the benefit ES suites produce, which is rooted in standardized and simplified business processes. Will this transition in ES take us backwards?
On the other hand, the transition may be beneficial. Perhaps the E 2.0 tools being added to ES suites will give rise to organizations that can more easily share knowledge and improve collaboration, despite any increased process and IT complexity. If so, then the transition will enhance firm performance and competitiveness and take us forward. The third option is that SaaS and E 2.0 will continue to grow, but by and large the promise of ES tools -- standardized business processes and efficient structured data management -- will continue, with firms slowly and steadily increasing their abilities over time.
Regardless of the final impact, the point is clear. This transition requires some attention. Firms should challenge some of their basic assumptions about their ES portfolio and reexamine the portfolio in light of recent consolidation and general advancements in the tools. How firms think about and select ES tools matters. How they choose to deliver their ES solution -- via inhouse hosting or a SaaS model -- may matter. The user-centric capabilities of E 2.0 also merit a close look. And the way firms will be deriving strategic advantage from ES is likely to shift, too. What firms do next will determine the collective outcome.
"The Transformation of the Enterprise Software Market"
Cutter IT Journal, Vol. 21, No. 6
by E.M. Bennatan
The divide-and-conquer approach to software development fits in well with the massive move of software development toward consumer and Internet-based products. In the fast-moving highly competitive environment that now characterizes much of the software market, small fast steps are often the only means for survival. This means that the evolutionary (or divide-and-conquer) approach to software development was and is inevitable.
by Steve Andriole
A common practice for large enterprises is a process known as "optimization audits." These audits are designed to assess and recommend opportunities for making money or saving money with technology by looking at areas like applications, data, networks, organization, leadership, governance, and architecture. The mechanisms for achieving "make money/save money" results fall into several categories, including learning, awareness, and executive education.
We've have learned that it's essential that the business technology team on both sides of the aisle understand technology trends, business models, how to interact with each other, how to conduct due diligence, and even how to develop a business technology "road show." We've also learned that well-conceived and well-delivered learning programs can help enormously. In fact, they are essential. The need for a common language, a common understanding, and managed expectations is real and continuous.
by Curt Hall
Dynamic visual analysis is applicable to a range of analytical and decision support applications. Obviously, traditional BI analysts and other power users can use it to enhance their statistical and other complex analyses. However, I recommend that organizations look beyond these typical power users and carefully consider how they can apply dynamic visualization to support their more casual users -- for example, to enhance the functionality of dashboards and scorecards and other metrics-displaying applications. Finally, I suggest that organizations examine how dynamic visual analysis can be used in conjunction with wikis, search, social networking, and other collaboration environments. This will help extend the benefits of BI to more classes of users throughout the organization; in effect, allowing organizations to benefit the most from their enterprise BI efforts.
by Lynne Ellyn
As in all invention and construction activities, the method should fit the problem. One might choose to landscape the backyard in an agile way, choosing hardscape, and then trees, then flowers, then patio furniture. If the problem is the construction of a skyscraper in Tokyo where the building is subject to frequent earthquakes, agile approaches would be a disaster, although the creative design phase might be a perfect agile project requiring close work between architect and client.
Fitting the methodology to the problem is not a backlash because methods are tools, not religion. There are better and worse choices, sometimes optimal choices, but never perfect choices. Judgment and experience are the most important in choosing the best development method for a given project. Judgment is a byproduct of experience. Experience is what you get by making mistakes. You make mistakes because you lack judgment. This is an iterative process, but we can't call it agile because it takes years. We call it wisdom.
The best story I ever heard about the process of choosing a methodology for a project comes from our good and wise friend, Ken Orr. Ken was once called in as an advisor to one of those gargantuan projects that only the federal government could possibly conceive. Ken was asked, "What methodology can be used to effectively control a project involving thousands of people -- a project expected to take at least 10 years to complete?" Ken's answer: "None known to man." That's wisdom.
"Waterfall Backlash"
Business Technology Trends & Impacts Council Opinion, Vol. 8, No. 4
by Lou Mazzucchelli and Tim Lister
We think of agile methods as a family of approaches aimed at dealing with uncertainty. If there is a high level of uncertainty about what exactly you will end up building, then the agile approaches (all of which call for multiple short iterations with ongoing customer feedback) make enormous sense. With the agile methods, we incrementally steer our way to a useful system. On the other hand, if there is a clear and explicit definition of what needs to be built, then the iterative approach significantly decreases in value, and a preplanned, classic, phased approach may be sensible.
"Understanding Perceptions of IT Agility"
Cutter Benchmark Review, Vol. 8, No. 4
by Gabriele Piccoli
Since I started my PhD, back in the day, I have been a subscriber to the pendulum theory of human affairs. It goes like this: human endeavors -- organizational trends are no different -- are characterized by overshooting swings of the pendulum to which reaction trends emerge, until the pendulum overshoots to the other side and a new countertrend develops. Organizational examples abound. Consider some of the most significant consulting trends of recent memory: First we had business process reengineering, characterized by hyperefficiency and downsizing, but with downsizing came loss of institutional knowledge and organizational memory. The following trend developed as a reaction: knowledge management.
The pendulum theory also plays out in the waves of integration technology. We had business integration through enterprise systems and data integration through data warehouses. These integration techniques are based on centralization and standardization. Emerging for some time now has been the countertrend of agility, and mashups represent one of the tools in the arsenal of those who want to achieve agile data integration and visualization in the enterprise environment.
"Enterprise Mashups: Time to Get Down to Business"
Cutter Benchmark Review, Vol. 8, No. 3
by Carl Pritchard
The heart of a business case is the simple explanation of how a given strategy, action, or approach is an improvement over an existing approach (or how a strategy, action, or approach is worth creating). That is coupled with the projected costs of implementation and maintenance versus the existing costs. At this point, revenues or savings may also be considered.
The problem with having employees generate business cases is that most of them don't know the real costs of implementation or the real values they bring to the organization. Ask a room of 10 employees how many know their "fully loaded" or "fully burdened" rate in most organizations, and you'll get half a room of blank stares. Most personnel don't understand that their cost to an organization is vastly higher than their hourly rate or salary. Instead, they labor under the misconception that they are worth their hourly rate, and unless they identify opportunities that optimize that rate, the opportunities are not worth pursuing.
Opportunities can be seized only if we truly know they are opportunities. And team members throughout an organization can't figure that out if they don't know the real value of the assets in the organization. A business case is much easier to justify if the metrics are visible and within the realm of normal understanding.
by Johanna Rothman
A cynical senior manager said, "It feels as if I'm stuck between the traditionalists and the agilistas. We can't use phase-gate anymore, because it's not 'agile' enough. And the last time, when that multisite project tried Scrum, they failed miserably. Isn't there a right approach to our projects?"
A project doesn't have to use just one lifecycle. In fact, the more geographically distributed and the more complex the project, the more each project site or area needs to choose its own lifecycle. Then you need a program manager to help organize all the interdependencies.
But too few project and program managers know about their choices for lifecycles. Without that knowledge, it's impossible to design a project, to reevaluate the risk as the project unfolds, and to use the lifecycle, or change it, in order to steer the project in another direction.
"What Lifecycle? Selecting the Right Model for Your Project"
Cutter IT Journal, Vol. 21, No. 5
by Jim Highsmith
Many years ago, I had a workshop exercise in which teams were given a set of requirements and asked to build a house of cards. Teams got points for height, surface area, ability to hold an object without collapsing, schedule, and so on. Finally, the instructor (me) awarded points for esthetics. Every team complained about the esthetics score! They felt that it was arbitrary and capricious -- it was. But it emphasized the point that part of quality is in the eye of the beholder (extrinsic), no matter what the team thought about its product.
Many management writers over the last couple of decades have come down squarely on the extrinsic side of quality -- that the customer is always right. Agile development is very customer-oriented. However, agile development is also very quality-oriented -- in the sense of intrinsic quality in the form of comprehensive testing. So maybe the questions about quality are not so much either-or, but both-and. Intrinsic and extrinsic quality are both important.
by Vince Kellen
I contend that heavy investments in IT tend to produce (or at least co-occur with) management practices such as decentralized decision-making, greater use of teams, broader job requirements, a more educated workforce, quality management frameworks, simplified and improved business processes, and better cross-department coordination. The technology makes some of these things easier (e.g., decentralized decision making, cross-department coordination), and it tends to require some of these practices (e.g., broader job requirements, more education).
This line of reasoning begs questions. Does lack of attention to organizational capital and its myriad of components cripple investments in IT? How much should a company examine its management practices when making large IT investments? Or should the firm simply invest in the IT and get around to the accompanying management practices later? At what point does corporate culture need changing in order to get the payoff from the IT investment? Is your company's culture well matched for the major IT investments made so far and to be made in the future? Are your competitors ahead or behind you in adoption of good management practices? What investments are they making that seemed timed with IT investments? Can or should you copy these practices? What collection of management practices are the magic elixir in your company, that when mixed properly, ignite the IT investment?
Too often discussed separately, the planning of investments in IT assets should be joined with the planning of investments in management practices.
"Organizational Capital: The Magic Elixir?"
Business-IT Strategies E-Mail Advisor, 25 June 2008
by Steve Andriole
The services area is about both saving money and making money. The key message here is about variety. Whereas just a decade ago there was a limited set of well-understood service packages -- help desk support, data center management, and customer service centers -- today, there's a complete range of services provided by a large number of skilled vendors. In fact, nontechnology executives and managers should understand that many startup companies are outsourcing just about all of their technology to managed service and total solution providers (MSPs and TSPs) that host hardware, software, and communications. Legacy companies are outsourcing more of their operational and strategic technology.
Executives and managers need to understand that there's a full complement of services available to them and that assessments about their core competencies should drive their sourcing decisions.
by Curt Hall
It's so trendy now to talk about "real time" this and business at "Internet speed" and so on. The bottom line is that, when practicing CRM, no matter what your strategy now, it's best never to forget the long-term goal. True, short term could get you some quick results. However, you also run the risk of possibly alienating some customers. On the other hand, engaging your customers in a manner that promotes a long-term relationship (i.e., the "R" in CRM) will show customers that you respect and value them. Anyone -- especially customers -- can appreciate these two things.
"Thinking CRM? Think Long Term"
Business Intelligence E-Mail Advisor, 24 June 2008
by Robert D. Austin
In the 1970s, some commentators argued that Moore's Law would be less important very soon, if for no other reason than that soon all the numbers that needed crunching would be crunched. They were wrong. They didn't take into account a whole lot, but most notably they missed the paradigm shift toward greater interactivity (GUIs and the like) that chewed up computing power not on input transactions, but rather on improving the user experience. I'd be very surprised if a future of higher bandwidth, ubiquitous wireless networks, huge amounts of storage, storage and computation moving out into the cloud, and, yes, chips still getting faster, does not come to pass and surprise us yet again.
by Gabriele Piccoli
On the viability side, sustainable IT has characteristics of security and risk management. I know these risks firsthand as I am an advisor to a startup based in Rome that focuses on streamlining electronic distribution for hotels and resorts. The cofounders of the firm always know when I teach security in my course. Invariably, once a semester, as I get ready for my lecture, I get an uneasy feeling about how much is at stake when security breaches occur. As I get that feeling, I call them up to be reassured that we have taken all the appropriate steps to mitigate all security risks. This is probably the same feeling you have all experienced once or twice (some of us more) when you have gone to boot up your computer and found that it does not start. We immediately think about the last time we backed up our files (in my case, typically a long time), and we get the sinking feeling of losing one of the most valuable things we have -- our data. The key is that a looming crisis often brews under the surface, but once it reaches its trigger point, it explodes to the surface. The fact that nothing major has happened yet does not mean that there is no crisis, but makes it easy to forget about it.
As ... I have become more interested in sustainability overall, I got the same feeling. So much is at stake when it comes to the viability of our planet, let alone our organizations, that it is our responsibility to make green IT and green IS a priority. But note that this focus on viability does not come simply at a cost. This is where sustainability shares important characteristics with the innovation and agility trends we have been covering lately. Sustainability and green IT create significant opportunities for organizations that are nimble and forward-looking enough to seize them. Green IT and IS can be great for business!
"Being Green: A Duty and an Opportunity"
Cutter Benchmark Review, Vol. 8, No. 5
by Carl Pritchard
If I determine that my roof is getting old and may spring a leak, I may decide to replace the shingles. If I know that a particular day is going to be drenched in rain, I may plan for indoor activities. If I suspect that I may lose a critical team member to a key competitor, I may take the time allowed me by identifying this threat as an opportunity to build the talents of a lesser team member. Or I may use it to develop an ongoing understudy program. Or I may use it to reengineer or "idiotproof" the process. While those may be seen as risk responses, think about them in the context of an opportunity. If we plan indoor activities, are we harmed if it doesn't rain? No! If we build effective understudies or a flawless process, does it harm the way we conventionally do work? No! If the roof never leaks, were the shingles of no use? No! We have seized opportunities to do good things for the organization. And we did so by binding them to the back of the threats that we face.
by Alistair Cockburn
[It is] the responsibility of both the project manager and the managers of project managers (whom I'll call "upper managers")
to get current with the field and to produce project success.
Upper managers might not know all the best modern practices. After all, that is not their primary job. They should, however, encourage, monitor, and hold PMs to account for learning and adopting good modern practices. They should know whether the PMs are practicing sound professional behaviors.
Beyond just encouraging, learning, and monitoring behaviors, the upper managers themselves -- not the PMs -- are accountable for many issues that drive project success or failure. Upper managers vastly underestimate the cost of communications on globally distributed projects, they frequently don't take the time to incorporate customer feedback within the project, and they often do not make business priorities clear. They are thus personally responsible for setting projects up for failure from the very beginning and standing idly by while things go predictably wrong.
"What Can We Do About Our Project Managers?"
Cutter IT Journal, Vol. 21, No. 5
by Ken Orr
As agile development gains further currency, it is in danger of becoming watered down. Agile development in the hands of traditional project managers is likely to become neither agile nor development. As this happens, it is particularly important for the best and brightest in this business to distill what the best features of agile development are. As I say, "You can fake everything but testing."
"Is Design Still Dead?"
Agile Product & Project Management Executive Report, Vol. 9, No. 2
by Vince Kellen
While it is quite obvious that firms exist to serve customers, it is not as clear why the business and IT strategy often does
not start or end with the customer. I have repeatedly seen the organizations I work with genuflect before the customer altar but
only show up in church once a year.
To understand what I mean by this, the next time you are in a meeting regarding a strategic decision at your firm, count how many minutes are spent on issues that are internal to the organization versus issues that specifically concern the customer who matters: the one who gives money to the firm. Also try to measure, even if it's a ballpark guess, the numbers of pages written about the internal issues in the firm versus the real issues that your firm's customers face. You will probably find that the decision makers in firms spend much more time discussing, designing, and planning actions around internal challenges than around paying attention to the customer's challenges.
Do a little further digging in your organization. Gather all the printed documents concerning the design of a manufacturing facility, a product, or a major IT solution and stack them up. Then do the same for documents that describe your firm's customers. I'll bet the stack of documents pertaining to facilities, products, and IT solutions is much taller.
by Curt Hall
BI has moved far beyond basic extraction, transformation, and loading (ETL) and canned reporting. The trend today is for
companies to apply BI techniques across the organization in a variety of formats. These formats range from basic reports
and analyses to dashboards and scorecards for performance management and even embedded analytic workflows (i.e., process-embedded
analytics) that tie together comprehensive metrics with business methodologies. As a result, both application and end-user data
access requirements can vary considerably. More to the point, not all end users need real-time analysis and reporting capabilities.
The other side is equally true: not all users require historical data to support their decisions. Still, it is apparent that new
applications and business needs are driving more organizations to support both real-time and historical data access/integration
capabilities.
To think that there is a "one-size-fits-all" approach that can satisfy all enterprise data integration requirements, however, is somewhat shortsighted. Most companies, I believe, require a data warehouse, which in addition to being updated periodically (typically, with daily and weekly refreshes), also uses change-data capture or trickle-feed methods. In short, nothing beats having a centralized store of standardized and cleansed (i.e., reliable) data that provides both a historical and current (i.e., daily or up-to-the-hour) view of the overall organization for general reporting and analysis purposes. However, I also think that most companies are going to require some form of EII or virtual data broker capability that can "snag" select data from key transaction systems and other sources in order to support more specific real-time or operational decision-support applications. These can include, but are by no means limited to, "at-a-glance" performance monitoring dashboards, business rules management systems (BRMS), CRM systems, and personalization platforms.
"And the Best Data Integration Technique Is ..."
Business Intelligence E-Mail Advisor, 10 June 2008
by Verna Allee
Thirty years ago, businesses were organized functionally. The organization chart became the way to describe how
the business works. In the mid-1980s, scholars like Michael Porter and consultants like Deming and Hammer led the
way to refocus work on process and quality control. Making sure you had a robust process was the key to efficiency,
productivity, and quality. Businesses reaped big rewards from business process reengineering, Lean, and Six Sigma.
Today, however, businesses are discovering that the "engineered" approach is simply not sufficient to bring growth and prosperity. The goal of process engineering is to drive out variation to achieve consistent outcomes. However, driving out variation also drives out innovation, flexibility, and agility. In fluid markets, and in the global supply chains and exploding innovation that are found in virtually every kind of business, variation is not only a given -- it is desirable!
So, how do you achieve consistent outcomes without driving out variation? The answer for many businesses is by systematically visualizing and deploying value networks. People have known for a long time that the real work gets done through informal networks. Now people are making those informal networks visible in order to better diffuse knowledge and expertise. Further, they are beginning to understand business itself as an ecosystem of value-creating networks.
by Jeroen van Tyn
A proven method for concentrating the mind is to have an actual project that has to get out the door.
People with this motivation are much more likely to see the value of, and thus spend the time doing,
the enterprise business modeling required to support their projects. The business models they create
will naturally focus on their particular parts of the enterprise. This means that as subsequent projects
come up, the enterprise models will be revisited and undoubtedly there will be corrections and elaborations
to things that had been modeled for previous efforts, because there are now additional perspectives being
brought to bear on the enterprise view.
Some see this as a bad thing, because it means that the enterprise business models were "wrong." The important thing to understand is that change is inevitable. Even if you somehow got your enterprise models absolutely "right," businesses change all the time due to market conditions, competitive pressures, budget realities, business opportunities, and so on. This means that models of the changing business will also have to change. It follows that you will have to tolerate changes to enterprise business semantics -- no matter what.
So plan on your business models not being "correct" the first or even the second time, or maybe ever. Plan on versioning service interfaces and enterprise messages. Plan to evolve your catalog of business events. Plan to make changes to the data models of your operational data stores. Plan to revisit applications to realign them with changing business semantics. And put the organizational structures and governance processes in place to manage this change.
by Robert N. Charette
What is clear from UBS's, GE's, and a myriad of other companies' experiences, is that enterprise risk is extremely
volatile at this moment in time, and that it is being almost universally underestimated. For GE, which is famous
for keeping extremely close watch on its revenue and earnings, to be taken off guard by extremely swift changes
in its markets sends a number of messages to anyone who bothers to listen.
First, ERM approaches in too many companies have been more for show than for improving decision corporate decision making. Enterprise risk management ... will be chucked overboard if it interferes with the corporation making money.
Second, even where ERM is taken seriously, the approaches have not been up to the task of dealing with market volatility effectively. Better ways of assessing, monitoring, and predicting strategic, operational, and financial risks are needed, especially in recognizing risk volatility and the impact of that volatility. Too many of the techniques, like Value at Risk (VaR), are based on backward-looking analysis and are nearly useless when a market changes in any fundamental way.
Third, better ways are also needed in making risk transparent not only to corporate executives but to shareholders. It seems pretty obvious that corporate executives and their boards of directors do not understand the types or magnitudes of the risks their business units take, and that ways to make these risks understandable to both of them is desperately needed. If the executives don't know what risk is being taken, shareholders can't be expected to know them either.
Fourth, check-in-the-box enterprise risk management cannot be tolerated. Improved measures of ERM compliance and performance are required.
Finally, it is clear that the future business environment is not going to get less "risk complicated" -- if corporations can't handle the risks that exist today very effectively, the next few years are likely going to be filled with a lot of nasty surprises, I'm afraid. A radical rethink of ERM is what is required, but unfortunately, little that I see being done in corporations or what I read in the literature makes me believe much is going to change anytime soon.
by Johanna Rothman
If you're the project manager, your obligation to the project -- no matter what processes you use -- is to improve
throughput and remove obstacles. This means you need to recognize what prevents throughput for your project. I'm not
a fan of serial lifecycles for long or large projects because there's little or no throughput for most of the project,
and it's too easy for project teams and project managers to miss early warning signs of trouble.
For any lifecycle other than serial, you and the project team receive feedback about the activities completed to date, and you might be able to measure your throughput. As a result, you can review where you are with respect to your schedule and where you wanted to be. If your schedule risk has increased, you can move to incremental development or timeboxes. If your technical risk has increased, you can move to prototyping in timeboxes. (My experience says that if technical risk has increased, schedule risk will increase quickly!)
You don't have to be "All Agile All the Time." Nor do you have to be "We're Phase-Gate and We're Proud." You do have the obligation to recognize where you are in a project and to decide what to do about it. Consciously selecting a lifecycle or combining lifecycles can help.
"What Lifecycle? Selecting the Right Model for Your Project"
Cutter IT Journal, Vol. 21, No. 5
by Jim Highsmith
As I have often said, agile management is the "art" of balancing. Early problems and issues can be the result
of inadequate planning or the result of uncovering information in early iterations that was unknowable through
planning. Could a little more planning have uncovered this problem? Did action (a development iteration) uncover
this problem faster than additional planning would have? These are the kinds of questions that need to be asked,
but the answers are often hard to come by. Traditional project plans are deterministic; they exude confidence.
Misplaced confidence, but confidence nonetheless. Agile plans, especially early ones, exude uncertainty -- they
point out explicitly where potential problems lie -- and plan to examine those problems early. A "confidence"
profile of a waterfall project starts high, remains high through early periods as requirements and designs are
documented, and then begins to falter as coding and testing begin exposing problems. In contrast, the "confidence"
profile of an agile project is lower early in the project but then increases slowly and then more rapidly over the
course of the project as features are built and tested and high-risk areas are mitigated.
This is one area, the early problem problem, where management needs to understand the difference between agile and traditional projects and react appropriately to improve project success rates.
"The Early Problem Problem"
Agile Product & Project Management E-Mail Advisor, 29 May 2008
by Steve Andriole
There are so many attitudes, perceptions, and best practices that have to change in order to wind down
corporate computing from what it once was. The drag of concepts like control, standardization, single
source (versus best of breed), and centralization can really limit progress toward the new era. This
is not to say that all of these concepts are bad. Standardization of network access devices, for example,
is a sound best practice, but which access devices should be standardized? Similarly, the centralization
of infrastructure can make sense, but how and where should it be housed, and who should house it?
How do legacy companies with legacy technology environments exploit open source software? Do they really want to, or are they committed to their proprietary partners? How do you develop the business case for alternative software providers? Can you send the crown jewels down the street or across the globe for safe-keeping? Or will you worry every night about where they really are, what they're doing, and who's wearing them?
The real challenge for legacy companies ... is liberation from past habits, values, business cases, hardware, software, processes, and services. The idea, for example, of importing widgets, APIs, and other tools from the Web to develop or extend applications scares the hell out of many CIOs and CTOs. If these technology managers are more than 50 years of age, the idea could be fatal.
by Vince Kellen
As simple as it sounds, to do IT well relative to competitors, all a firm needs are teams of people
that can learn quicker than competitors.
How quickly and adroitly individuals and teams master this knowledge challenge is perhaps the singular
difference between great, good, and bad IT. Great IT teams already have great knowledge and absorb new
knowledge very quickly. Good IT teams have some of this capacity but tend to lack the focus, energy, or
ability to persist for the length of time needed to become great. Bad IT teams have very little of this
knowledge-absorption capacity and are subject to endless and often reckless dissections by executive
management, who themselves lack this kind of knowledge-absorption capability. When trying to fix the
IT organ.ization with reorganization, most firms are like hack doctors, who know little of medicine
and biology proper, less about the specific disease afflicting the patient, and possess none of the
physical dexterity needed to properly wield a scalpel. We've seen the result so many times -- blood,
carnage, and screams -- and little if any improvement in IT productivity and effectiveness. CIOs come
and CIOs go. Organizational torture persists.
by San Murugesan
Virtual worlds are at the early stages of their development. If ongoing developments are of any sign
of how they will emerge, virtual worlds are poised to become an indispensable business tool and vital
to the strategy of any company intent on reaching out to the younger customers -- the video game generation.
Virtual worlds are on the cusp of a major expansion, and companies that ignore them will be doing so at
their peril, caution industry analysts. Any consumer-facing business has to be experimenting in virtual
worlds if it wants to get the attention of the under-30 crowd, who want to distinguish themselves in
digital spaces. So don't ignore virtual worlds or discount them as immature or as platforms for just
games; experiment with and embrace virtual worlds as appropriate to your activities.
Though there is a growing interest in embracing, or at the least experimenting with virtual worlds and their technologies, many companies find that it's simply too hard to become familiar with and get into these worlds in a significant manner. Currently, most of the agencies advising companies on their digital strategy (e.g., about how to run their Web sites) had traditionally been skilled in areas like graphic design, which don't necessarily translate well to virtual worlds. Virtual worlds have been criticized for being difficult to use and for failing to deliver any tangible benefit to companies doing business in it, which to date has mostly been marketing.
by Steve Barnett
As an anthropologist who has studied business organization styles, advertising, and younger employees,
I believe it is timely to explore the implications of newer networking Web sites and user values for
consumer trends, including limits on traditional advertising, misguided attempts to inject advertising
into networking activities, and innovative communication strategies. Younger people have moved on from
physical world networking to virtual networking and that changes their concepts of self, other, and what
matters in general. Traditional advertising assumes a "real" self that is consistent and can be targeted
for specific products. What's happening now is that virtual networking encourages multiple selves and
self-experimentation so that appealing to this "real" self is often irrelevant. Similarly for the "other,"
who can also be a temporary construct that can be modified quickly in Web-based interactions. This flux
creates an environment in which what is important at one moment becomes pointless at another.
My research (academic and business) suggests that advertising styles have evolved in a number of ways since WWII, despite most advertising agencies asserting the continuity of advertising methods and strategies. And that evolution will continue -- we need to understand what the next iteration of brand communication will be, rather than just assuming that the dead hand of competence is sufficient to create product differentiation.
Based on my research experience while teaching at various universities (MIT, Brown, Princeton) plus my business background (senior executive at Nissan North America, Citibank, and Ogilvy & Mather), I believe it is possible to understand these new forms of networking and their significance for advertising styles. That research needs to be innovative, evaluating how individuals actually use these networks and how that usage impacts their sense of self and their attraction for various products and consumption values.
by Lynne Ellyn
IT organizations and businesses in general are so consumed with the many tasks at hand and the
short-term focus on financial results that preparation for tragedy is rarely funded or adequately
comprehended. Two forces are at work: both are human. Humans habituate to normal -- whatever normal
appears to be. Normal is expected, and life is lived with the implicit belief that tomorrow will be
like today and preparation for tomorrow is simply a refinement of today's preparation and response.
My guess is that this is much like our other mammalian relatives who do not (as far as we know)
contemplate their own death or spend any thought in what-if scenario planning. Response to predictable
environmental change may get programmed in (think migratory behavior), but response to unpredictable
events like a massive meteor is dealt with if/when they occur. In extreme circumstances, animals cannot
respond to sudden change, and populations, even species, may be destroyed. The tendency to anticipate
only what has already been experienced operates in gerbils, people, and social institutions like governments
and businesses.
by Robert M. Mason
Managing paradoxes may be the biggest challenge to an executive who seeks to lead an innovative organization.
In the late industrial era, traditional strategic wisdom suggested that firms would choose to compete either
on lower costs (economies of scale, driving down the cost of production by using the learning curve) or on
innovation (rapid and continual introduction of new products). The innovative leader, however, recognized
that it was not "either/or." Instead, the firm needed to be both a cost leader (e.g., from process innovations)
and a product innovator (i.e., introducing new products). The leader of today's innovative organization is one
who seeks out the "paradoxes" in conventional wisdom and finds ways to change "either/or" to "both/and" --
to reconcile what at first appear to be absurd and contradictory options, conditions, and requirements. Doing
this is what will make the firm succeed with innovation by changing the nature of the competition.
by Gabriele Piccoli
To state that agility is critical in today's increasingly turbulent environment is almost a tautology.
But for as widely accepted as this notion is, creating and managing an agile enterprise remains an elusive
and difficult task. I was reminded of this difficulty in my most recent case study on Hilton Hotels Corporation.
Hilton is a behemoth of an organization with more than 3,000 hotels in more than 70 countries and managing nine brands in every segment of the hospitality industry. Not content with this, it is set to open a new property every two days for several years in the future. Its complexity and diversity notwithstanding, Hilton runs off of a standard enterprise infrastructure built on best-of-breed applications collectively named OnQ -- as in "we are ready to serve guests on cue." But serving guests "on cue" inherently requires the ability to be flexible and responsive in your interactions with them: every guest is unique, so every interaction needs to be unique. How do you structure an organization that at the same time is able to deliver a consistent level of service -- the critical success factor for any global brand -- and yet serve individual guest needs? You do it by tackling both aspects of your information systems: the technical and the social. You ensure that your system architectures have inherent flexibility from both a design and a use standpoint. You then develop a culture of improvisational capability within the boundaries of brand-defined service levels -- clearly not an easy task!
"Creating and Managing the Agile Enterprise"
Cutter Benchmark Review, Vol. 8, No. 4
by Oliver Sims
The term "architectural style" comes from Richard Hubert's book Convergent Architecture (Wiley, 2001).
The idea is that just as in the sphere of building architecture, there are recognizable styles (e.g., gothic cathedral,
office building, or domestic residence), so are there similar styles or kinds of applications or systems or infrastructure.
An architectural style is defined as a reusable holistic design for designing and developing IT systems (i.e., a design for successful designs), describing a family of designs that are related by similar properties and relationships. Note that an architectural style is not necessarily "greenfield": it often takes existing IT landscape into account and provides it with long-term evolutionary direction as well as a short-term reference frame.
Put another way, an architectural style talks about a cohesive and mutually supportive set of processes, structures, and designs that together supports the design and build (whole lifecycle) of several IT systems of the same general kind. An architectural style defines its goals as well as its intended scope of application. It includes or refers to, but does not necessarily "own," one or more architectural principles.
"Packaging Architecture for Reuse"
Enterprise Architecture Executive Report, Vol. 11, No. 2
by Jerry Peterson
Risk assessment involves aggregating and summarizing information, potentially a great
deal of very detailed information. A quantitative risk assessment requires estimating
both the magnitude of a potential loss and the probability that the loss will occur.
The magnitude may be quite complex to estimate, but at least it should be approachable
with standard techniques -- say, cost analysis. Estimating the loss probability can be
more daunting. Ideally, we would use frequency data about similar events in the past,
but such data may not be available, or the conditions surrounding past events may be
so varied that comparisons are unreliable. The alternative is to use subjective probability
estimates from people who are knowledgeable about the project situation, but this, too,
is problematic. First, the set of people available and qualified to make such estimates may
be vanishingly small. Such people need to have broad experience of similar situations in the
past, and they need to understand the current situation well enough to judge its similarity
to their past experiences. Then, too, it has been shown that people attempting to make direct
probability estimates tend to have certain biases, such as overconfidence. Because of these
issues, some researchers challenge the very idea of asking people to make direct probability estimates.
"Risk Assessments? You Bet!"
Enterprise Risk Management & Governance Executive Update, Vol. 5, No. 4
by Jim Highsmith
In many projects, the fuzziness of scope allows two groups to have very different expectations
about what will be delivered. One group, usually product management, envisions a gold-plated
capability, while the development team envisions a bare-bones one. Constrained sizing can help
bring these expectations into line early in the project. It is easy to misinterpret a scope
description to meet one's own expectations (no matter how much time is spent defining that scope).
It is much harder to misinterpret a sizing number; for example, 60 SP.
Early sizing in project release planning is inexact no matter which method is used. Attempts at defining scope and estimating often end up wrong, as projects unfold and teams learn more about the requirements. Similarly, sizing by constraining can give a false sense of correctness, particularly if little thought is given to the "reasonability" of whether adequate functionality can be delivered within the capability timebox. For early release-planning efforts, both types of sizing should be used. Scoping and estimating is preferred for some capabilities, while timeboxing is preferred for others. They can even be used together -- timeboxing to get into a ballpark, then scoping and estimating within that ballpark. It is necessary, however, to keep track of which capabilities are sized with each method. This approach can also be used for iteration planning, but it is probably more useful when planning extended time frames.
For constrained sizing to work, all parties -- the development team as well as product and executive management -- need to understand the benefits and the limitations of such an approach. However, I have found that timeboxing size rather than estimating size can be another useful technique in the agile project manager's toolbox.
by Steve Andriole
Communication is continuous, so don't think that one briefing will change everyone's
perspective or attitudes about the business value of technology. But a well-conceived,
well-delivered briefing will begin a positive process. Nontechnology executives think
that they know enough about technology, but chances are they have only pockets of insight.
Technology professionals need to complete the picture for their colleagues. That is
primarily because the nontechnology executives and managers cannot complete the picture
for themselves. In much the same way technology professionals would find it difficult to,
without any help, complete their understanding of marketing, manufacturing, or distribution processes.
by Curt Hall
The problem with mining blogs, message boards, online forums, and other social media
is that it requires the use of text-mining tools that can analyze unstructured data.
Similar to structured data mining, text mining uses sophisticated algorithms, such as
neural networks, case-based reasoning (CBR), probabilistic reasoning, advanced statistical
methods, and other machine learning techniques, to automate data analysis and discovery in
unstructured data. But a key differentiator between the two is that text mining can also
makes use of natural language processing (NLP) techniques, such as lexical processing and
analysis, word/phrase parsing, and other methods, to enable text mining systems to identify
and highlight key concepts and relationships among words in text. All of these techniques,
however, are not widely understood by most corporate IT departments. Consequently, the mining
and analysis of unstructured data is not widely used by mainstream organizations.
"Why Mining Internet Social Media Is Difficult"
Business Intelligence E-Mail Advisor, 8 April 2008
by Tim Lister
It is unlikely that you are in the airline business, but can you concoct a scenario,
or, as in JetBlue's case, a cascade from an event that could stress your business to
its snapping point? Can you convene subject matter experts from different parts of
your business and have them follow the business reaction to the triggering scenario?
Look at business systems, not just computer systems. Where are the limiting factors?
When does the business system "max out"? It is not enough to practice risk management
on new projects and products. If you are operating on a different scale than when the
business process and its implementation were defined, you may well be running on sunny
day optimism. In 2001, when most of its systems were already implemented, JetBlue had
15 airplanes. Some glued-together packages and some part-timers working out of their
kitchens made a lot of sense in 2001, but galloping growth and "one day at a time"
made those systems inadequate for anything but the sunny day.
"Sunny Day Optimization"
Business Technology Trends & Impacts Council Opinion, Vol. 9, No. 3