Archived Quotes of the Day
by Carl Pritchard
The art of risk management is the art of clairvoyance. Risk management is the ability to both foretell the future and to do something about it.
Risk management has long been analyzed in the context of business financials, organizational behavior, project breakdowns, and individual perspectives and attitudes. In each instance, it has largely been focused on the risks of a given point in time and a given set of circumstances based solely on today's knowledge. There are alternatives, however, that to-date have not gotten much press and may hold promise for increasing our ability to look at risk from a more comprehensive, lifecycle perspective. It's an examination of risk from the consumption-chain perspective.
by Kenneth Rau
In the last few years, there has been a renewed and more pervasive interest in performance management programs in IT. I believe this is the result of two complementary factors. First, in a down economy, ambitious projects tend to give way to cost control and the need to demonstrate value for the expenditure of precious corporate resources. Performance measurement/reporting as a control program in IT has always flourished in the troughs of economic cycles. Second, we have seen the introduction of business intelligence software that has removed the drudgery of manual, intensive generation of performance reports. This, in my opinion, is what has accelerated and sustained interest in IT performance programs this time. Both generic tools and tools designed specifically for reporting of the IT function have emerged that enable automatic capture of IT performance data and its presentation in summary form (dashboards) with drill-down capability for the exploration of anomalies.
by Jim Highsmith
Most agile transitions happen in two to three "waves" of effort. An early implementation of one to three projects expands in subsequent waves to more projects. During the initial projects, the best way of handling organizational process issues is usually to gain "exceptions"
to those process requirements. Each of these exceptions should be noted and eventually handed on to a team that is responsible for overall process changes so that agile methods become the norm rather than the exception.
Failure to anticipate the myriad of organizational process issues affected by an agile implementation can severely hamper progress. On the other hand, proper attention to these issues can actually help promote agile concepts more widely in the organization and raise significant support for the agile transition effort.
"Agile Integration -- Organizational Processes"
Agile Project Management E-Mail Advisor, 4 May 2006
by Ken Collier
Today's companies are more open to outsourcing than ever before. It can enable them to more quickly realize the value offered by business intelligence while remaining focused on their own core competencies.
However, today's companies are rightfully concerned about relinquishing control of their information assets and understanding the value proposition of utilizing a business intelligence (BI) provider.
Organizations should take a disciplined approach to outsourcing, starting with a clear understanding of the value proposition to set the right expectations. Once understood, delineation should be made between the company's existing BI competencies and the areas of BI that are best handled by an outside expert. Evaluating candidate vendors should focus on vendor experience, commitment to the target objectives, and the ability to structure a pricing model that is directly tied to success.
BI outsourcing will be most fruitful if it is a true long-term partnership between client and vendor, and if both parties stand to gain by the success of the initiative.
by Steve Andriole
Most IT organizations are cost -- not profit -- centers. Senior executives (except for the CIO and CTO, of course) are always trying to reduce technology expenses. A friend of mine -- a CIO at a major insurance company -- gets a memorandum every quarter from the CEO asking him to reduce technology expenses by 10%. He keeps telling him that if he were able to reduce technology spending by 10% -- quarter after quarter -- eventually technology would be free. This silly dance has been going on for years.
But there may be another way to skin the cat. Instead of trying to cut costs quarter after quarter, year after year, how about if we think about generating revenue from technology? By revenue I don't mean that usual challenge thrown at CIOs and CTOs ("use IT to generate more sales and profit") but revenue generated by selling technology expertise and capacity.
by Tom Welsh
The founders of the free software movement -- especially Richard Stallman, the doyen of free software gurus -- understood perfectly well that the progress of software was being seriously bogged down by the inertia of the capitalist enterprise.
If software, and intellectual property in general, is treated as a scarce, valuable commercial asset, it will be jealously guarded so that the maximum profit can be wrung from it over its whole lifetime. This mindset drops a whole series of miniature iron curtains between companies and their developers, striving to restrict knowledge as a miser hoards gold. Once we let software be free -- as in "free speech,"
preferably as in "free beer," too -- a chain reaction will develop, letting developers "stand on the shoulders of giants" (or at any rate, each other) and thus stop incessantly "reinventing the wheel."
by Carl Pritchard
There are individuals afraid to begin the risk conversation in any
organization. Why? I hear it from our client personnel time and again.
"We're risk averse around here. Management doesn't want to admit there
are risks. They tell me to come with solutions, not problems, and then
they tell me that I should have warned them about the risks." These are
not uncommon complaints and concerns. What's tragic about them is that
they stifle the risk conversation in an organization. Risk becomes
equated with whining, and as a result, the discussion is kept to a minimum.
Management can turn this around, if they (the management) are willing to
be the ones to initiate the risk conversation. It can be done -- and it
can be done without initiating a jeremiad from those responsible for
handling the risks at a lower organizational or project level. Part of
the basic challenge is keeping the conversation focused on risk as a
future phenomenon. Risks may be driven by the prevailing organizational
environment, but as yet, they have not happened. As such, we're still in
a position where we can do something about them. Starting the
conversation needs to include a basic structure for how the discussion
will be framed:
I wanted to get your input on some of the risks we face on this effort,
but I want to stay focused on those things that are still in the future.
I need some answers to this question: "What are some of the bad things
that may yet befall us and what may they cause?" There may be a
temptation to stray into insights about WHY they're going to happen to
us, but I don't want to go into that in as much depth yet, as that's
where folks often get bogged down in these discussions.
by Mike Rosen
As often as not, EA is its own worst enemy in terms of demonstrating or
delivering value to the enterprise. One common scenario is "EA for EA's
sake," in which the EA program is intently focused on developing EA
artifacts. This frequently involves an EA framework or toolset, which
tends to direct EA activities toward filling out the framework or
populating the tool's repository. Now, there is nothing wrong with
frameworks and tools. Frameworks provide valuable guidance and
conceptual organization, and tools help to catalog assets, manage
relationships, and generate reports. But too often EA programs treat
frameworks and tools as the end products instead of as the means to
achieving an end that delivers value to the organization.
Another common scenario is "Death by Architecture," where the
architecture group strives toward a complete and comprehensive solution.
Only when the architecture has addressed all the issues facing the
enterprise is it ready to be released and distributed, perhaps in the
form of a multivolume document set totaling hundreds or even thousands
of pages. Another word for this is "shelfware" -- the architecture
documents look spiffy on the shelf, and having them there demonstrates
how smart you are to be able to understand the architecture.
Unfortunately, in many cases they are never opened again, and certainly
not by the development organization. Even more likely, the architecture
is out of date before it is ever released because it failed to keep up
with changing requirements and technology during the 2+ years it took to
produce.
"Best Practices in Enterprise Architecture: Opening Statement"
Cutter IT Journal, Vol. 19, No. 3
by Jim Highsmith
A frequent source of misuse of experience and talent comes from creating a matrix management structure in which experienced software managers are given functional, HR-oriented management roles while project managers manage development teams. Organizations need roles and role descriptions, but they should not allow these to get in the way of leveraging ability. Possibly the most important job of managers is putting the right people and the right mix of people on a team. They do this by understanding individuals, not roles or skills.
Assembling effective agile teams requires thinking about individuals, their abilities, their personalities, and the mix of all these traits within a team. But assembling these teams is only the start -- the managers and team leads must constantly work on team interactions, encouraging communications, and resolving the conflicts that arise periodically when teams are working so closely.
"Agile Integration -- Assembling a Team'?"
Agile Project Management E-Mail Advisor, 13 April 2006
by Helen Pukszta
The step of assessing the business impact is necessary to close the loop that ties the investment back to the initial project proposals and business cases. It is a step that, unlike the one-time assessment of the project performance, typically has to take place over time. Once an IT investment is implemented, its success depends on the environment into which it was introduced: customer acceptance, user motivation, marketing, effectiveness of new processes. It is after the completion of the project, during that period of business adjustment to the new system and ways of working with it, that crucial steps can still be taken to steer the investment in the right direction, and to find ways to further increase its value. Yet too often IT-based initiatives are in essence abandoned as soon as celebrations die down after the official completion of the project.
by Curt Hall
The point I'm trying to make is that expert systems are fairly complex decision-support applications that utilize rules to capture and model the "deep" knowledge and expertise of a subject matter expert or complex environment. Please don't get me wrong, people are still developing expert systems. However, companies are much more likely today to use rules engines to develop decision automation applications that involve much "shallower" reasoning than what we have come to associate with traditional expert systems.
The bottom line is that the major use of business rules engines today has shifted toward organizations applying the technology to automate deterministic work-oriented or repeated decisions. Such applications typically involve high-volume decision making (in which a high degree of reliability is demanded) such as credit approval, fraud prevention, differentiated services, and other customer management decisions -- as opposed to complex decision support tasks requiring the application of deep expert knowledge. Other popular decision automation applications in which rules engines are being utilized include managing compliance and implementing advanced workflow and dynamic process and application integration capabilities in IT architectures.
"Why 'Business Rules Management Systems'?"
Business Intelligence E-Mail Advisor, 25 April 2006
by Christine Davis
Energy costs are an overhead expense that is very difficult to budget and manage, especially given the highly volatile energy markets in today's economy. It is extremely difficult to sort out all the drivers for our higher energy bills. As [Cutter Business Technology Council Fellow Tom DeMarco] predicts, the bill is growing higher due to the consumption demands of today's electronic equipment, but various cost drivers, which will take the cost accountants a lot of analysis to isolate, are contributing to the increase as well. More than likely, the attempts to manage the ever-increasing energy bill will be similar to the efforts we saw some 20 years ago when electricity cost was first recognized as a problem. There will be an effort to reduce the cost by adding on efficiency controls at the macro level. Many of us probably remember the installation of timers on the lights in our buildings and the beginning of the daily reminders to turn off your computer before you leave. (We used to turn them off simply to save energy; now we turn them off for security reasons, as well as to save electricity.) Companies will need to continue to take advantage of the technologies coming to market that help manage power consumption. But this will not be enough to offset the increased cost of electricity, a necessity of doing business.
Businesses will continue to be driven to make their expected profits, so productivity gains will be necessary to offset the increased energy-cost escalation. Despite efforts to remove any unnecessary consumption of energy, electronic purchases will continue. The only viable solution will be to increase revenues or increase productivity in other areas to meet the financial goals. The focus will continue to be on meeting the "bottom line."
by Scott Ambler
I believe that traditional EA teams are set up to fail from the very beginning. Not on purpose, mind you -- I can't imagine anyone funding an EA team simply for the entertainment value of watching it fail (OK, this is something that Catbert might do) -- but more due to a lack of understanding of the realities of modern software development. The EA teams I've seen would often produce white papers and models that the developers would never read or, if they did read them, would soon forget. The EA teams would review architectures, often after the fact, and provide feedback that the development teams didn't always follow.
It's easy to blame developers for the challenges EA teams face, but you need to take a look at it from their point of view. The EA team often has interesting ideas, but the architects always seem to focus on a long-term vision that just doesn't seem to match the short-term goals of the current project. Or the EA team writes great white papers, but the developers have never seen the architects write great code, so what does the EA team really know? The EA models look impressive, but the developers really don't understand the notation or, if they do, the implications conveyed by the models. There is often a disconnect between software developers and enterprise architects, one that can be overcome by avoiding common EA anti-patterns and adopting a more agile approach.
"Making Enterprise Architecture Relevant to Developers"
Cutter IT Journal, Vol. 19, No. 3
by Karl Wiig
The management of knowledge -- that is, the active initiatives to govern knowledge-related processes, activities, and human behaviors -- has the purpose to better attain the enterprise's goals and objectives. KM rests on the premise that better knowledge and improved access and application of knowledge will make the enterprise more effective in areas such as internal operations, customer understanding, success in the marketplace, financial performance, and general stakeholder relations -- all general measures of enterprise success. The notion is that application of better knowledge will result in better and quicker decisions, increased innovation, and greater relevance to the achievement of goals in all work. Knowledge, it is argued, is the underlying factor that fuels people's intellects and thereby makes good performance possible.
However, as James Quinn states, "Surprisingly little attention has been given to managing professional intellect" [Quinn, James Brian et al.
"Managing Professional Intellect: Making the Most Out of the Best."
Harvard Business Review, 1 March 1996.].
Without knowledge, intelligent and effective behavior -- the ability to interpret, assess, understand, innovate, decide, act, and monitor -- will not be possible even if the best information is made available.
"A 2005 Perspective on Knowledge Management Practices"
Cutter Benchmark Review, Vol. 6, No. 3
by Tom Welsh
One way of understanding the luxuriant proliferation of free and open source software (F/OSS) packages is to think of license fees as analogous to gravity. The resulting commercial CSS ecology consists of a few compact, strongly built organisms stumping phlegmatically about their business. The constant "gravity tax" sucks away most of their energy; every movement is an effort. But in the low-gravity or zero-gravity world of F/OSS, there is unbounded excess energy; a fantastic menagerie of creatures, big and small, leaps and cavorts everywhere, giving free rein to curiosity and creativity.
by Rob Thomsett
The active involvement of senior management as project sponsors and steering committee members is critical to successful agile projects. To implement agile development and agile project management without engaging executives in the changes that they must adopt to support the real benefits of agile development would result, at best, in the limited adoption of the agile paradigm. At worst, lack of executive buy-in into the changed roles for executives required for agile project governance would result in failed implementation of a powerful model for project development and support.
"Agile Project Governance"
Enterprise Risk Management & Governance Executive Report, Vol. 3, No. 3
by Scott Ambler
Database refactoring is a database implementation technique, just like code refactoring is an application implementation technique. You refactor your database schema to ease additions to it. You often find that you have to add a new feature to a database, such as a new column or stored procedure, but the existing design is not the best one possible to easily support that new feature. You start by refactoring your database schema to make it easier to add the feature, and after the refactoring has been successfully applied, you then add the feature. The advantage of this approach is that you are slowly, but constantly, improving the quality of your database design. This process not only makes your database easier to understand and use, it also makes it easier to evolve over time; in other words, you improve your overall development productivity.
by Steve Andriole
The key is the extent to which board members are kept apprised of technology issues, challenges, and major projects, and the extent to which technology executives develop relationships with board members much like COOs, CFOs, and CMOs have before, during, and after board meetings.
So is the board essentially unaware of technology at your company? Or is there a mechanism to keep the board informed about -- and involved in -- technology? If the truth be told, companies that regard technology as a necessary expense to be managed probably see little need to keep their boards informed about technology -- except perhaps to announce further reductions in technology spending (about which the CFO is extremely proud). But companies that invest in technology for strategic purposes should keep their boards very informed about how technology investments will help generate revenue and profit.
Is there risk in communication with boards about technology? Some, since boards tend to be relatively weak in technology strategy, and project updates can be misinterpreted. In other words, effective communication will often require education, or boards may become anxious about, say, a US $100-million ERP project that's behind schedule and over budget.
Education assumes a commitment of time and resources and perhaps even a planned technology discussion at every board meeting. But all this assumes a desire to keep the board informed so that board expertise can be leveraged for technology acquisition, deployment, and support decisions, especially to the extent that such decisions are strategic.
"Boards of Directors and IT"
Business Technology Trends & Impacts E-Mail Advisor, 23 March 2006
by Curt Hall
Automating customer-interaction decisions across multiple channels
requires combining historical customer information with real-time
information acquired by monitoring transaction processing systems, which
can include ERP, CRM, customer contact centers, e-commerce, and wireless
servers. This requires implementing an architecture that allows the
integration of BREs with these different enterprise applications. To
date, the use of BREs for multichannel decision automation has been
limited mainly to larger companies in industries that tend to rely on IT
as a source of competitive advantage (e.g., banking, financial services,
insurance). This is because the concept is still fairly new to most
organizations. Moreover, implementing the necessary architecture has
been difficult due to a lack of standards and best practices for
implementation. However, several developments indicate that things are
changing.
For one, the use of BRM technology -- and business rules in general --
is now receiving considerable corporate attention. Moreover, the
development of standard APIs and frameworks for Web services and
service-oriented architectures (SOAs) now offer a practical means for
integrating BREs into corporate production environments. Basically, the
advent of Web services and the SOA was probably the best thing that
could happen for business rules implementation. The BRM vendors quickly
recognized this, and they have made supporting these standards a top
priority. As a result, we are now seeing organizations deploy BREs using
various architecture configurations, including as a J2EE Enterprise
JavaBean (EJB), model-driven bean (MDB), or Web service. Other
configuration options include deployment as a COM/MTS object, a .NET
component, or as a functional component that operates within EAI layers
and enterprise messaging and middleware systems (e.g., IBM MQSeries,
J2EE, Java Messaging Service [JMS]).
by Carl Pritchard
The concept of an independent organizational risk office has an amazing
appeal. If we just open a risk office, they'll be able to channel the
practice in the proper direction and get everyone on board. The allure
of consistency, common understanding, and professional vision is almost
too tempting to resist. This is a call to resist it.
While a risk office may be able to establish the proper practices in
terms of what should be done to drive effective project and
organizational risk management, there is a dark side. The risk office
can also become a key driver of complacency and a bulwark of the
"not-my-job" mentality. Risk management is effectively accomplished at a
variety of levels. A single voice or the voice of a single office cannot
effectively capture the breadth of understanding within an organization.
Risk is born out of experience, and the more experiences that can be
brought to bear on the subject, the more effective the risk management
practice will become.
by David Hussman
Whether a community uses a story wall or a higher-tech tracking system, the stories need to remain the single source for planning, tasking, and measuring progress. The further a community moves from the simple and highly visible nature of a story wall -- for instance -- the more discipline is needed to ensure the stories remain manageable in size and highly visible/available. It is also important to monitor how easy it is to find and change stories -- both stories in development and stories queued up for future development cycles.
More visibility and ability to change (as business needs change) will always correlate with higher fidelity and increased ability to accurately track when projects are succeeding or struggling.
by Helen Pukszta
We do need managers who are driven by schedules and budgets; little would get accomplished without them. But we also need managers in charge of projects who are value watchdogs and who understand that the drive to meet target schedules, budgets, and user expectations should not take precedence over the drive to maximize business value. Measures such as on-time/on-budget/in-scope statistics are only as good as their ability to approximate that business value. If tradeoffs between keeping on schedule and producing additional benefits appear, as they often do, they have to be recognized and handled appropriately.
If we are failing with IT, it is in ways much different from schedule and budget overruns. A preoccupation with timelines and budgets penalizes deviations that could prove more beneficial to the business than staying the course. Obsessed with meeting deadlines and in the name of success, IT organizations will avoid projects with significant business payoff when there's high uncertainty. They will pursue what is manageable and predictable rather than what is challenging or difficult to estimate yet has significant business potential. They will protect themselves with the aegis of project metrics and signoffs. They will avoid failure. By doing so, they will help the business avoid innovation through IT and the potential for success that can come with it.
"Rethinking Success and Failure in IT"
Business-IT Strategies Executive Update, Vol. 9, No. 6
by Curt Hall
One of the major issues with text-mining technology has been the degree of expertise and learning curve required for building applications. In particular, creating the directory structure or taxonomy necessary for capturing unstructured and semi-structured data from various customer touch points (customer comments in e-mail, etc.) and integrating it so that it can be analyzed has proved beyond the capability of many rank-and-file businesses. This has been aggravated by a lack of suitable taxonomy and other classification tools. Consequently, application development has frequently required the use of highly specialized consulting services, making implementation costly.
Although many issues still remain with text mining technology, it appears that organizations are beginning to feel more comfortable using it -- or are at least willing to investigate text mining. Several developments are responsible. For one, text-mining products have advanced over the past few years with the development of new visualization and user interface techniques. General advances in XML have also helped to ease integration and manipulation of textual information. In addition, the technology is becoming embedded in other software applications.
"Text Mining for Business Purposes"
Business Intelligence E-Mail Advisor, 21 March 2006
by Mike Rosen
EA and SOA can, and do, provide significant value to an organization if given the time to achieve critical mass. Getting enough time requires both providing value and meeting expectations along the way. Don't fall into the trap of overpromising what will be achieved. Resist the temptation to follow the overhyped media expectations. Instead, make realistic estimates that if anything "underpromise" on the returns so that your architecture efforts can meet, or exceed goals, overcome skepticism, and "overdeliver." Unmet promises or unexpected hero, which will it be?
"Underpromise, Overdeliver"
Enterprise Architecture E-Mail Advisor, 1 March 2006
by Johanna
Rothman
Senior managers -- the people who make strategic product
decisions -- need to know when they can expect those products
to release. The organization of current product releases
against a timeline is a project portfolio. And, planning the
project portfolio in an agile environment is different -- but
not harder -- than planning the project portfolio in a
non-agile environment. With non-agile projects, we tend to plan
and use the portfolio as an ordered list of projects slotted
into timeslots. But with agile projects, we have the
opportunity to replan the portfolio as we understand the
projects and the market. Instead of planning a series of
projects, we can slot a series of features into a particular
iteration and estimate the number of iterations required before
a release. The hardest part of the portfolio work is making
sure we (the managers, project managers, and product owners)
have gathered all the work. The work in an organization
consists of project work, ad hoc work, periodic work, ongoing
work, and management work. I want to make sure our portfolio
reflects all the work we do, including the unstaffed work, so
we can make good decisions about when to start which
work.
"Agile Portfolio
Planning"
Agile Project Management E-Mail Advisor, 16 March
2006
by Borys
Stokalski
Building a business case is a necessary prerequisite in
supporting any major investment decision. Building the business
model, calculating costs and quantifying benefits, analyzing
cash flow over time, and calculating financial indicators, such
as net present value, internal rate of return, return on
investment (ROI), or whatever else is required for getting the
management approval, are essential parts of "investment
engineering." This is the kind of discipline that creates
informed and responsible spending decisions, right? Well,
perhaps not really. Occasional chats with decisionmakers of
various organizations, which have in time turned into a sort of
countinuous informal research, combined with the experiences of
the consulting organization I work for, make me think that the
truth differs from the preceding "business-case-by-the-book"
statement. In many situations, people confirm that a business
case is built and evaluated (should we say tweaked?) after --
not before -- the investment decision has been made. Thus a
process intended to be an essential tool for making decisions
becomes a ritual aimed at fitting already-made decisions into
the corporate rules of the game.
"The Mythical Business Case
-- Part 1: The Limits of Rational Decisions"
Business-IT Strategies E-Mail Advisor, 8 March
2006
by Ken
Collier
Not only is BI outsourcing an emerging option for many
companies, according to our findings, but it is becoming a
mainstream practice. The on-demand ASP model is perhaps the
best poised for adoption by today's companies. Providers that
offer on-demand SFA, such as Salesforce.com, represent a
rapidly growing category of hosting companies whose primary
focus is on outsourcing business processes. As a natural
occurrence, these companies also capture and manage the data
associated with such business processes. By virtue of this
fact, these providers are automatically the BI provider as well
as the ASP. The smart ones understand this and offer analytical
services that are tailored to the BI needs of their customers.
However, a major concern with hosted applications remains in
their reliability and availability, as witnessed by the recent
service interruption at Salesforce.com in mid-December 2005
(during the height of holiday buying season). Providers whose
primary focus is in hosting business intelligence (versus
business process automation), such as data warehouse hosting or
data mining outsourcing, are not experiencing the same rapid
growth as the on-demand model. However, the capture and
analysis of business data continues to increase exponentially.
And, as companies also increase their utilization of IT
outsourcing, I expect to see a rising demand for hosting models
that offer comprehensive end-to-end BI services that are not
necessarily tied to a single business process.
"BI Outsourcing Becoming
Mainstream"
Sourcing & Vendor Relationships E-Mail Advisor, 1
March 2006
by Curt
Hall
One roadblock standing in the way of greater adoption of
business rules practices is a lack of industry standards for
production rule languages and modeling languages. Today, most
vendors' business rules management (BRM) products use their own
proprietary rules language. What is needed is a standardized
rule representation for production rules that features portable
rules syntax. This would allow organizations to apply BRM
technology across different projects using different vendors'
products. It would also be very useful if business process
modeling (BPM) and enterprise architecture tools could
reference a common format for expressing business rules that
could be converted into a common production rule
representation.
"Business Rules Standards
Efforts"
Business Intelligence E-Mail Advisor, 7 March
2006
by Lou
Mazzucchelli
The typical modern laptop computer has several features that
should strike fear into the heart of corporate executives and
IT management. One is an increasingly large amount of mass
storage, now measuring in the hundreds of gigabytes. Another is
integrated writable DVD drives and support for large USB
solid-state "disks." Still another is built-in wireless
networking, currently topping out at 54 Mbit/s but on its way
to gigabit speeds in less time than anyone might expect. Each
of these features alone poses a challenge to corporate
information integrity and security -- how many of you have
banned CD drives from corporate desktops to minimize the
introduction of malicious data or software into your systems?
We have all read stories about hapless executives "losing"
their portable computers on business trips (and as I was
writing this came the story of an external auditor leaving an
unencrypted CD containing 9,000 employee records from his
client -- a computer security company -- in an airplane seat
pocket ... ). Some of these are actually due to carelessness;
others are glossed-over instances of industrial espionage.
Let's face it: in a typical large corporation with a
substantial number of mobile employees, more corporate data is
at large, and more ports are potentially open to the corporate
network than any manager wants to admit. Think about your
company: it's 10 pm -- do you know where your data is?
"Anchors Aweigh: Fat Laptops
Considered Harmful"
Business Technology Trends & Impacts Council
Opinion, Vol. 7, No. 2
by Bill
Walton
Two alternative but related approaches to traditional
budgeting that many companies are exploring are rolling
forecasts and "beyond budgeting." Unlike traditional budgeting,
rolling forecasts are reviewed on a monthly or quarterly basis
and include only a few line items, which are typically linked
to an enterprise balanced scorecard and, therefore, are a
mixture of financial and nonfinancial measures. By connecting
the allocation of resources to specific performance measures
and using the balanced scorecard's inherent cause-and-effect
model, rolling forecasts push managers to take a more
forward-looking view of the business and allow companies to
react more quickly to market changes.
"The Role of Strategy,
Planning, and Budgeting in an Agile
Organization"
Cutter IT Journal, Vol. 19, No. 2
by Jim
Watson
The happy path for a project is one where things proceed as
expected, on schedule, and within a (probably very narrow)
range of expected results. The sad path -- sadly, more familiar
-- is the one whereby there is uncertainty, doubt, and real
issues that pop up unexpectedly and are not easily dismissed or
addressed. Having issues, missteps, hiccups, and failures
should not be a problem -- they are to be expected. The real
problem is when these issues are detected, assessed, and
allowed to influence decision making, as well as how they are
resolved. Conventional wisdom is that earlier is better and
that more frequent information on smaller issues is better than
either less frequent information or issues that have larger
implication. Agile methods' concepts of releases and iterations
encourage an organization to find and confront issues sooner.
Therefore, you need an organization that is comfortable with
dealing with issues as opposed to being derailed by them ("Oh
no, here we go again!").
"Ensuring Releases Contain Lots
of Implementation"
Agile Software Development & Project Management
Executive Update, Vol. 7, No. 2
by Tom
Welsh
No statically mandated security regime can hope to succeed for
long in today's fast-changing IT world. Security must be
treated as an ongoing process, not a policy, a state of
affairs, or a product. Moreover, it is essential to track and
record events (through logs and other methods) and review
security incidents and responses at frequent intervals. This
way, if a culture of vigilant security awareness can be
established, it will be possible to initiate a cycle of
continuous improvement, allowing enterprises to keep ahead of
the ever- developing threats confronting them.
"Searching for the Optimum
Level of Security"
Business-IT Strategies E-Mail Advisor, 1 February
2006
by Curt
Hall
For the past three years or so, companies have been striving
to optimize their business processes and activities through the
use of the "two BPMs": business process management and business
performance management. For the most part, practitioners from
both camps have viewed the techniques as mainly separate. The
former has focused on analyzing and optimizing business
processes but has run into trouble due to difficulties
encountered with integrating data from disparate systems. The
latter has focused on monitoring and measuring different key
views of the organization but has not been able to live up to
its expectations because it has been weak in the area of
process support. The ERP vendors thought they were ideally
situated to capitalize on both business process and business
performance management -- because their enterprise applications
support a range of processes. However, go beyond those
processes actually supported by their ERP modules, and the ERP
vendors quickly run into all kinds of data integration and
transformation problems, meaning that it is very difficult to
monitor and analyze other key enterprise processes that reside
outside of the ERP framework. As a result, it has become
increasingly obvious that enterprise data management must be
made a top priority for improving business processes. And this
is where companies are going to run into a lot of trouble:
trying to tie together all their diverse processes in a manner
that can make sense of all the data those processes generate
and/or must have access to in order to support their business
operations. The bottom line is that this is where IBM and the
other consulting organizations are going to make all their
money: helping companies tie together and orchestrate all their
data and processes.
"Merging the Two BPMs:
Opportunities Abound"
Business Intelligence E-Mail Advisor, 21 February
2006
by Steve
Andriole
It really is about attitude and money. Companies that see
technology as a profit center see business models and processes
differently from those that regard it as an unmanaged expense.
They proactively look for ways to improve business models and
processes with technology not in spite of technology. They
track technology trends and creatively apply technology to
customer service, product personalization, and supply chain
planning and management, among other activities that touch
customers and markets. These companies invest in their
technology profit centers in much the same way smart companies
invest in excellent sales and marketing organizations.
"Cost Versus Profit Centers: The
Proof Is in the Spending"
Business Technology Trends & Impacts E-Mail
Advisor, 9 February 2006
by Robert
N. Charette
Information responsibility is a term coined long ago by the
late management theorist Peter Drucker. Drucker said that
everyone in an organization has to ask themselves, "What
information do I need to do my job? How am I going to get it,
and from whom? And how do I know that it is true?" Furthermore,
each person must also ask, "What information am I responsible
for? What do I have that others need? How do I ensure that I
can communicate it to them?" To Drucker, information is the
life blood of organizations. An organization without
information will slowly bleed to death. One that creates and
then uses poor information will develop blood poisoning. One
that stifles the truth will die of self-asphyxiation.
Information responsibility is a personal thing. No one can make
you practice it. In many organizations, information is power,
so some people deliberately choose to withhold it from others.
In others, many choose to suppress information, especially "bad
news," from going up the organizational ladder. And in still
others, many choose not to listen to the information that is
being presented to them. Probably the worst of all the
practices of information irresponsibility is self-suppression,
where an individual chooses not to speak out when something is
wrong because of the fear of being wrong, or being embarrassed,
or the fear of retribution.
"Remembering"
Enterprise Risk Management & Governance E-Mail
Advisor, 2 February 2006
by Carl
Pritchard
With the proliferation of project management standards in
different cultures and organizations, speaking to the
differences becomes a major challenge. Just being able to speak
the language of all these varied organizations creates a set of
headaches, exacerbated by the passions with which proponents
argue that their standard is the one true standard by which all
others should be judged. In some organizations, the standards
take on a nigh-religious status, and those who fail to "preach
the gospel" of their given standard are seen as heretics (or,
worse, as less-than-professional professionals). The challenge
for the strategist and professional becomes knowing how the
different standards align (and fail to align) and which
elements of the language are crucial to the appearance of
understanding and organizational acceptance.
"Standardizing the Standards:
Picking Project Management Standards and Guidelines that Match
Culture and Strategy"
Agile Software Development & Project Management
Executive Report, Vol. 7, No. 1
by Helen
Pukszta
Ask yourself: Have your technology proposals or decisions ever
been influenced by what you thought was good for your IT team?
Mine have. Though, of course, at the time I believed they were
good for the business as well. Once I witnessed an IT technical
lead break down crying out of frustration that a project he was
hired to work on had been delayed for another three months,
this after a year of waiting while keeping busy doing
maintenance work. I felt his pain. But I also saw his hiring
manager's error in bringing people on board whose sole ambition
was to work with a specific technology. It is natural for an IT
manager, or any manager for that matter, to protect, guide, and
nurture those who report to him. But it is an instinct with
particular consequences in IT because of the strong group
identity typical of IT departments -- an identity generally not
shared by the rest of the organization. Peppered with a few
recalcitrant but influential personalities, some IT groups
assume a surprisingly coherent worldview that is just as
surprisingly at odds with the thinking of the rest of the
business. (I have found that the excessive use of the pronoun
"they" in conversations when referring to the world outside of
the IT department is a strong indicator of an existing conflict
between the IT group and the rest of the organization.)
"The Balancing
Act"
Business-IT Strategies E-Mail Advisor, 8 February
2006
by Tushar
Hazra
A strategically chartered global delivery model for sourcing
can unify the geographically dispersed workforce and eliminate
cultural barriers, thus promoting a united organization. This
model will (1) help the internal resources or employees to
collaborate effectively with the sourcing partners; (2) utilize
an appropriate set of technologies; and (3) develop a
consistent process toward achieving common business goals. It
will improve the quality of service delivered to the customers
and also enhance the productivity of the overall workforce. It
will assist with incorporating best practices, complying with
industry standards, and meeting government regulations or
mandates. Finally, such a model will indoctrinate the workforce
in using a common set of technologies across the enterprise
that can in turn help workers share the same user experience
all across the board.
"Creating a Global Delivery
Model for Your Sourcing Initiatives"
Sourcing and Vendor Relationships Executive Summary,
Vol. 7, No. 1
by Ken
Orr
Complexity is killing us and it doesn't have to. We need to
reduce the high-order complexity of our systems and our
programs. But we can't program our way out of complexity, we
have to architect/design our way out! Recently, I read a long
article on ways around the "buffer overflow problem," which
continues to allow hackers to break into our operating systems.
We know how to solve the problem -- make it a systems error
with no return -- but there are some presumed performance
problems, so we add complex, tricky code to try to get rid of a
design problem and instead confound our difficulties.
Complexity doesn't scale! It's much like Michael Jackson used
to say of optimization, which is the reason most often given
for complex design, "Don't do it, and if you have to do it,
don't do it yet!" Every generation of new hardware often erases
the need for the previous generation's complex optimization
schemes. But complexity, once loosed on the software world, is
nearly impossible to take back, because, naturally enough,
people take advantage of it.
"Complexity Doesn't
Scale"
Business Technology Trends & Impacts E-Mail
Advisor, 2 February 2006
by Mike
Rosen
SOA is hard to build. Services are hard to build. J2EE didn't
solve the problem. Web Services didn't solve it. (Hmm, sounds
like a presentation I've given....) Will service component
architecture (SCA) solve it? You be the judge. What technology
vendors continue to do is to raise the level of abstraction
that developers need to deal with and to separate what
applications do (the interface) from how they are implemented.
All this is well and good, but it only addresses a small part
of the problem. You need an architecture that defines how your
services support the enterprise business and information models
and how they fit together to support enterprise goals and
business strategies. And, you need analysts and designers
skilled in defining those services. I'm sure SCA will help make
systems more flexible and extensible, and when it's supported
by tools, you should think about using it. But don't forget the
architecture.
"Service Component
Architecture"
Enterprise Architecture E-Mail Advisor, 1 February
2006
by Robert
N. Charette
There are many aspects of current software risk management
practice that, if not rectified, will begin to injure risk
management's credibility and thereby keep it from reaching its
full potential. The greatest threat I see is the proliferation
of quick-and-dirty (Q&D) approaches to performing risk
management. While sometimes these are well-meaning attempts to
get an organization or software project on the path to using
risk management, they are more likely to push the project over
a cliff. There is an old rule of thumb that states that
everything should be made as simple as possible, but no
simpler. This rule seems to get broken quite regularly with
respect to implementing risk management on software projects,
at least given the number of risk management programs I keep
untangling.
"Quick and Dirty Risk
Management"
Enterprise Risk Management & Governance E-Mail
Advisor, 19 January 2006
by Scott Ambler
Gone are the days of naively trying to identify all of the requirements
up front, attempting to create the perfect design that fulfills those
requirements, and then building the software, often months or years
later. In theory this sounds like a good approach, but reality proves
otherwise. The Standish Group's Chaos Report v3 includes statistics from
"successful" traditional/serial projects, which identified detailed
requirements up front and delivered software into production. Although
most of these projects were late or overbudget, for the point of the
exercise they were considered successful. Participants were asked, "Of
the functionality that was delivered, how much is actually used in
practice?" The survey found that 45% of the functionality was never used
and 19% was rarely used. As far as I'm concerned, this is nearly
two-thirds wastage, yet the traditional community considers this a
success? Well, at least they got some software out the door.
"Opening Statement"
Cutter IT Journal, Vol. 18, No. 12
by Carl Pritchard
No matter the standard or guidance selected, there is a single key to
success -- consistency. Consistency is the reason for the existence of
the standards and guidance in the first place. They were created to
afford organizations a clear sense of how they can be capable of
repeating successful performance in the highly variable environment
created by projects. In implementation, however, some organizations may
be tempted to make minor or individual modifications in the process
applications on a manager-by-manager or project-by-project basis. This
is definitely a situation where individual goals and preferences do not
add depth to our capabilities and efforts. Instead, individual minor
modifications may undermine the ability to transfer projects from one
project manager to the next or to generate the support documentation
that may be incumbent on you as a component of the guidance. Enforcement
of such consistency can become problematic, in that the "enforcers" are
often those in a project management office (PMO) or project support
office (PSO), whose role is supposed to be one of support and
encouragement of best practices in project management. Because process
enforcers are sometimes perceived as process zealots or process police,
the key will be for these individuals to identify the clear benefits to
the end users for each step in the process and for enforcement of the
consistent implementation. If the PMO staff can effectively communicate
how the individual steps in the process render tangible benefit to the
end users, the end users become far more likely to apply the processes
in the way in which they were originally intended to be applied.
However, if it is seen as purely an administrative effort with limited
real-world utility, then ad hoc application is likely in its future.
"Standardizing the Standards: Picking Project Management Standards
and Guidelines that Match Culture and Strategy"
Agile Project Management Executive Report, Vol. 7, No. 1
by Bob Benson, Tom Bugnitz, and Bill Walton
We have observed considerable enthusiasm for portfolio management over
the past few years. CIOs and CFOs in particular are beginning to
understand that controlling the IT spend in a disciplined, holistic
manner adds real power to management's ability to focus IT on the right
things and to achieve greater business value. Based on experience with
our clients, however, we have also observed the need for some management
common sense to go along with the enthusiasm. Portfolio management is
not magic -- it requires the same kind of common sense as any other
effective management practice in order to achieve its benefits. From our
experience, we suggest four areas in which management common sense is vital:
1. Complete application costs
2. Achievable goals
3. Actionable results
4. Avoidable complexity
"Portfolio Management Common Sense"
Business-IT Strategies E-Mail Advisor, 11 January 2006
by Tushar Hazra
Over the past few years, I have observed a significant change in the
sourcing trends. Before the dot-com era, the majority of sourcing
delivery models, as presented by most recognized outsourcing vendors,
primarily leveraged the availability of talented workforce offshore as
an advantage. During the dot-com era, as meeting the end users'
expectations and exceeding their satisfactions became important,
sourcing models included the presence of the workforce onshore and
onsite to establish customer intimacy and to raise customer confidence.
During the post-dot-com era, sourcing is not all about offshore
development, and it is not all about customer intimacy; instead it is a
combination of all the options with a caveat of cost savings, use of
innovation and collaboration, and the ease of governance to maintain the
necessary control over sourcing initiatives. It is about utilizing a
global workforce.
In reality, a global sourcing delivery model must be created starting
from the day practitioners realize the need for sourcing in their
organizations or the enterprise. From its inception, the sourcing
delivery model must focus on meeting the end customer's expectations.
The model must be flexible enough to accommodate growing business needs
and to meet appropriate vendor relationships.
"Creating a Global Delivery Model
for Your Sourcing Initiatives"
Sourcing and Vendor Relationships Executive Report, Vol. 6, No. 1
by Rob Austin
In the formula "chunk it, routinize it, digitize it, automate it, and send it
offshore," only the very last part is at all new. The "chunk it, routinize it,
digitize it, automate it" is the bread and butter of what we have done with IT in the
last three decades or so. We sometimes beat ourselves up for project failure rates
and suboptimal investments in IT, but the fact is that business in developed
economies has been dramatically transformed by IT managers busy at chunking,
routinizing, digitizing, and automating. As a profession, we have created immense
value in this way. It is what we really -- really -- know how to do. In the future,
however, that work is likely to happen increasingly in low-labor-cost environments.
Businesses in developed economies will capture much of the value of having work done
in lower-labor-cost places, but if you are an IT manager who doesn't plan to move to
Bangalore or Beijing, you'll eventually have to figure out other ways of using IT to
create value.
Specifically, you'll have to learn how to create value by supporting the creation of
novel and valuable things, and this will not be about chunking, routinizing,
digitizing, and automating. Creating value by creating new things is not about
routinization or automation in any traditional sense. If you automate a process, you
ensure your ability to re-execute it. But if you execute the same thing twice, you'll
get the same result. Creating new things is not about value extracted from consistent
re-execution of the same processes. It is about new processes, with surprising
characteristics and unexpectedly valuable outputs. Our automation reflexes will not
serve us well in efforts to create anew.
"The Future of IT Value Creation in a
Global Economy"
Business Technology Trends & Impacts Council Opinion, Vol. 6, No.
12
by Gabriele Piccoli
The increasing importance, real and perceived, of computer security and
IT risk management practices creates a growing pressure on your
organization (what's new!) to make sure that you have your act together.
However, this pressure is not blind pressure. I think that the
uninitiated public does recognize that IT security is a difficult
business. Thus, companies that have clear safeguards and procedures in
place, those organizations that are up front about the challenges they
face and that don't attempt to cover up a breach if it were to occur,
will be rewarded in the arena of public opinion.
"Security: A Game Worth Playing"
Cutter Benchmark Review, Vol. 5, No. 12
by Mike Rosen
The demonstration of value is key to the position, reputation, and importance of an
EA program. In order to demonstrate value, you must know what value is and be able to
measure it. The first step is to understand what values are important to the
organization and how EA can help deliver them. Next, design metrics to measure and
show that value, and implement the metrics in the architecture and projects. Finally,
collect the measurements, report on them, and use them in a program of continuous
improvement. When something is important, we measure it. Most enterprises have
mechanisms in place to monitor and manage business processes, but few have similar
mechanisms for IT processes and productivity. Start to emphasize the value of EA and
IT by measuring it.
"EA New Years Resolutions"
Enterprise Architecture E-Mail Advisor, 18 January 2006
by Carl Pritchard
Most business is based on planned opportunity. Risks are taken specifically in order
to ensure that there is profit, process improvement, or shareholder growth. It is the
very nature of business to seek out opportunity. These sought opportunities are
planned and normally have some consistent characteristics. They are in keeping with
the organization's business models. They have clear, direct benefit to the
organization and its ongoing operations. They are touted as the organization's raison
d'être. Internal planned opportunities are the easiest type of opportunities to
get others to understand and concur with. These opportunities are sold in boardrooms
around the world. Unfortunately, in many instances, these carefully planned
opportunities are the only opportunities evaluated. And in the absence of causal
opportunities and external opportunities, there may not be sufficient rationale to
pursue these more conventional prospects. In many cases, these types of opportunities
are based on financial business models (ROI, IRR, NPV, EVA) with no consideration of
the secondary opportunities or the risks that afford them to occur. When someone
suggests that a new element of work presents a wonderful business opportunity, not
only should the specter be raised that there may be some inherent risk, but also the
notion should be put forward that the true benefit to the organization cannot be
evaluated without an assessment of any obvious external or causal
opportunities.
"Opportunity Knocks ... But Which Opportunity Is
It?"
Enterprise Risk Management & Governance Executive Update, Vol. 2, No.
20
by Scott Ambler
[D]ata professionals currently find themselves playing catch-up. Having missed the
object revolution of the 1990s, they also missed the adoption of evolutionary/agile
techniques, thereby limiting both their productivity and their ability to effectively
support development teams. Worse yet, they often equate modern approaches with the
"code and fix" techniques that the traditional approaches addressed. With the advent
of the traditional approaches, the pendulum swung from the hacking end of the process
spectrum to the bureaucratic end. The data community is just now coming to realize
that evolutionary/agile techniques are the happy medium between the two.
This difference in approach between the software development and data communities has
had dire consequences. For too long, organizations have suffered from infighting
within their IT departments -- project teams point their fingers at the "data
dinosaurs," who move too slowly and are difficult to work with, and the data teams
point their fingers at the project teams, who are in too much of a rush and ignore
their advice. There is a kernel of truth in both claims, but if the data teams are
truly responsible for data activities, then the onus is on them to find ways to work
effectively with the development teams.
"Opening Statement"
Cutter IT Journal, Vol. 18, No. 12
by Tim Lister
It seems to me that we need some safe way for people to declare that they smell the
Dead Fish of Failure on their own project. I don't know how to do that yet. I am not
asking that all projects be framed so as to guarantee success (guarantees are for
children); but is it crazy to ask that 50% of projects are outright winners? Once
people have truly succeeded, they are addicted to success, and they will do their
utmost to succeed again. As managers, we owe it to our staff that everyone gets a
taste of outright success, if for no other reason than the productivity boost it will
bring. Remember, only projects with a chance can do great things.
"Agile Methods and Risk"
Agile Software Development & Project Management Executive Update, Vol.
7, No. 1
by Kenneth Rau
Whatever the organization's motivation for undertaking an assessment of its IT
function, whether in response to discontent, required by management or a due
diligence effort, or as the precursor to strategy, no standard way of proceeding can
be prescribed.... I have always found each assessment effort to be unique, therefore
requiring an up-front determination of what is appropriate for the organization, the
situation, and the assessment's purpose.
Studies of the organization's current state in preparation for developing or
revising strategies, plans, and direction can and have been done in days, weeks, and
months. I would advise against prolonging the period in which the assessment is
performed for more than three or four months. To do so risks a blurred picture and
organizational fatigue. Taking only a few weeks runs the risk of omissions,
oversights, and the perception and reality of superficiality. Eight to 12 weeks seems
to work best for most.
As stated above, assessments are performed for a variety of reasons. As a result,
the environmental atmosphere for the assessment can run from confrontational to
exploratory. Most often, it is the former, and in these cases be sure you are
perceived as an impartial third party and emphasize the collection of quantitative
data from incumbents so conclusions are harder to challenge.
Finally, the canvas to use in painting the context is the business environment,
strategy, objectives, and maturity, for these determine whether findings about IT
processes and assets are consistent, realistic, and appropriate. To skimp on
understanding the business's vision and direction as part of the assessment is to
risk charting a course for IT that causes a divergence from its primary mission of
providing the organization with the technological wherewithal to be successful.
"The Art of IT Strategic Planning: Building the
Context"
Business-IT Strategies Executive Report, Vol. 8, No. 12
by Jeffrey Kaplan
[A recent Cutter] survey shows that not only has software-as-a-service (SaaS) become
a viable alternative to traditional packaged software applications, but independent
SaaS providers are building a solid base of satisfied customers who view them as
strong suppliers rather than risky startups. The rapid success of the independent
SaaS providers is pushing the established ISVs to quickly add SaaS components to
their product portfolios. This escalating competitive pressure drove Microsoft to
accelerate the development and introduction of its Web-based Windows Live and Office
Live offerings. As Gates stated in his internal memo about SaaS: "This coming
'services wave' will be very disruptive." The evolution of SaaS as a viable
alternative to traditional applications and the maturation of its leading providers
as real competitive threats to ISVs were also directly responsible for Oracle's
acquisition of Siebel, which was struggling to keep pace with Salesforce.com. The
good news for organizations considering SaaS is that escalating demand is attracting
more providers to the market -- creating a "buyer's market" for SaaS solutions.
"Selecting the Right SaaS Provider to Meet Your Business
Needs"
Sourcing and Vendor Relationships Executive Update, Vol. 6, No.
24
by Curt Hall
Data warehousing and BI should be thought of as strategic applications as opposed to
just some supplemental capabilities to be added to enterprise systems as an
afterthought. The importance of this view can not be overstated. Until recently, the
latter was the primary view held by the majority of organizations. Today, the
majority subscribes to the former. As a result, 2006 looks to be a great year for
data warehousing and BI because the (practical) tools and techniques are now
available to extend and enhance the ability of BI applications to monitor and analyze
business processes and activities across multiple departments, divisions, and
channels. To be sure, roadblocks still stand in the way of implementation, but the
opportunities for organizations to reap substantial benefits from applying data
warehousing and BI in a strategic manner are there for those willing to make the
effort.
"My Thoughts on BI Trends for 2006"
Business Intelligence E-Mail Advisor, 3 January 2006
by Tom Welsh
For all the talk of software disasters and project failures, modern programmers
routinely achieve great things. Hardly anyone could be found to deny that Windows XP
is far more stable, solid, and secure than some of its ancestors, such as Windows 95
and Windows 98. Yet it is also many times bigger and more complicated. Visual Studio
.NET is reliably reported to contain over 43 million lines of code, with 700
developers working in more than 30 teams; but it is the world's most popular
integrated development environment, and it works reliably enough even if it is
sometimes a little slow. Everywhere you look, there is clear evidence that some
programmers are doing superb work. There is no reason to suppose that the best of
today's programmers are any worse than the best who ever lived; but even they cannot
deliver results unless process, schedule, environment, management, and a hundred
other things are right.
"Is the Standard of Programming Rising or
Falling?"
Business Technology Trends & Impacts Executive Update, Vol. 6, No.
18
by Gabriele Piccoli
Security is a constantly evolving area for a number of reasons: first and foremost,
the breathtaking pace of technical evolution. Every new technology and software
program ushers in a unique set of security and risk management challenges that should
be proactively addressed -- whether that means taking specific steps to manage it or
consciously accepting the risk. Not surprisingly, a large number of our respondents
find it necessary to update their overall risk strategy at least annually and roughly
half of them have decided in the past to forgo the acquisition of a computer system
due to security concerns. Second, there is the issue of regulation. As computer
systems and networks increasingly become the backbone infrastructure that controls
the delivery of services and supports the global economy, it is likely that IT
security will attract more and more attention from regulatory bodies. While
regulation is probably inevitable, regulation itself carries its own set of problems
and risks. [C]ompliance does not ensure security, and by claiming compliance, a firm
may abdicate its responsibility to take ownership of the security problem. Finally,
there seems to be rapidly increasing media scrutiny and attention from the public to
the issue of computer security -- an issue that, because of its complexity, has
traditionally remained in the realm of the "initiated." This media and public
attention is, in my opinion, a good thing. After all, the increasing prevalence of
computer systems as well as the growing amount of our personal data that is stored by
business firms, nonprofit organizations, and governmental entities (and can therefore
be compromised) suggests that even the uninitiated public should pay attention.
"Security: A Game Worth Playing"
Cutter Benchmark Review, Vol. 5, No. 12
by Mike Rosen
EA has an enterprise scope; i.e., it spans all divisions, lines of business, and so
on. This puts it in a unique position within the enterprise to understand the entire
set of systems and applications that exist. The early focus of most EA programs is
the development of an IT inventory that identifies all of the applications and the
hardware and software systems that support them. Now, to demonstrate the value that
EA brings to the enterprise, it needs to provide that information as a service to
decision makers. This means providing the information in a way that directly supports
the decision making process. For example, providing an IT portfolio view that readily
identifies applications and their costs, value, importance, alignment, and so on, so
that decision makers can make intelligent budget decisions about IT expenditures. Do
not expect business decision makers to use the EA repository directly. Although this
is sometimes possible, it is almost always better to provide targeted reports that
support their decision processes.
"EA As a Service Organization"
Enterprise Architecture E-Mail Advisor, 14 December 2005
by Carl Pritchard
Every action has an equal and opposite reaction. While that axiom may not hold true
in the business world, there is sufficient evidence that it does carry a grain of
truth when pursuing opportunities. As new projects and programs are undertaken, there
is an inherent level of risk. But with each risk comes some opportunity. Some of the
greatest inventions are believed to be the fruit of causal opportunity: Champagne was
"discovered" by accident in the late 1600s during a misstep in the fermentation
process. Columbus's encounter with the New World. Velcro. Penicillin. X-Rays. Post-it
Notes. These were not the aim of their inventors. They were outcomes that were
wonderful, but unintended. The key was not that they happened, but that when they
happened, those who encountered them knew what to do with them. How many wonders have
been lost to shortsightedness? Causal opportunity can only be optimized in an
organization when the organization has an openness to mistakes and a willingness to
acknowledge the potential they present. In far too many modern organizations, the
notion of risk as failure has driven cultures to push errata underground, rendering
them lifeless. Instead, when discussing opportunities with staff and team members, it
should be emphasized that every risk event carries with it some measure of
opportunity, if we are willing to open our minds to the possibilities and to open our
cultures to accept that some bad things happen on good projects and programs.
"Opportunity Knocks ... But Which Opportunity Is
It?"
Enterprise Risk Management & Governance Executive Update, Vol. 2, No.
20
by Ken Collier
Typical database development involves building the data structures, writing some
code to access the database, running the code, then writing some queries to verify
that the data got into the database. Even the most rigorous database testers
generally verify a database by running several queries and visually inspecting the
results for validity. The problem with this approach is that as changes are made to
the database, we don't generally rerun all the old test queries to revalidate that
everything is still fine. Even if we do rerun the old queries, the task of visually
inspecting the results quickly becomes overwhelming. Rerunning automated tests is
painless and transparent (as long as the tests keep passing). It provides continuous
assurance that new changes don't adversely impact already working code. Test cases
provide documentation and make it easier to understand other people's code and
intentions.
Automated test-driven database and data warehouse development offers a unique set of
challenges. However, with a little effort, agile software testing concepts,
principles, and practices can generalize to provide a powerful framework that
significantly exceeds traditional database testing practices.
"Agile Database Testing"
Cutter IT Journal, Vol. 18, No. 12
by Donna Fitzgerald
Within IT, project management is considered a "middle-management" profession just
like any other technical discipline. Unfortunately, one downside of the decision to
break project management off as a unique discipline from general management is that
we've removed ourselves from the general management promotion pool. One of the paths
back into the pool is ... being able to speak the language of money. In theory at
least, the primary job of a senior manager is to make sure that the resources (i.e.,
money of the company) is being spent in a manner that furthers the company's ability
to earn a profit and to be successful in the marketplace. By presenting oneself and
one's project as an exercise in detail in which the goal is delivering neat
technology wizardry, we all keep ourselves down.
"The Nimble Project Manager and the Language of Money,
Part 2"
Agile Software Development & Project Management E-Mail Advisor, 15
December 2005
by Helen Pukszta
It is possible to do everything that is required of the business-IT innovation
function and put the old "IT R&D" label on it. I would caution against that,
however, for reasons similar to why we no longer call the IT department data
processing: the function and the scope have changed. Equally important are reasons
pertaining to culture and perceptions. IT R&D is still reminiscent of the
failures of the dot-com era and in lean times can be considered downright wasteful.
It may be best to do what marketers learned to do a long time ago: introduce the
improved product under a new name. Whatever you call it, however, the key is to
develop the processes and organizational ability to identify and pursue
strategy-consistent and differentiation-focused IT investments. And it is best to do
so without the limitations of traditional IT R&D.
"The Trouble with IT R&D"
Business-IT Strategies E-Mail Advisor, 14 December 2005
by E.M. Bennatan
In the broader context of business and security, how sensible is it for companies to
promote global workforce policies? In particular, is IT offshoring a safe business
model? First, indications are that global integration of technology workforces will
continue to grow, and this is a reality that IT companies cannot ignore (yet another
elephant). While security concerns are very real, they do not seem to deter the
global integration trend. Apparently, safety may be a short-term consideration, but
overall it does not appear to significantly affect offshoring. Second, companies must
make their decisions on offshoring on the basis of their own cost-benefit analysis
(and not because offshoring is fashionable). As Vestring et al. have stated,
piecemeal offshoring, without an overall corporate strategy, is not a good way to go
about it. As we have seen, offshoring has become a major factor in global business,
and IT companies must develop a corporate strategy to deal with it. And finally, a
sound approach to offshoring requires not just a corporate strategy but also an
organized process for implementing the strategy. This is a subject to be confronted
now; it can no longer be put off because offshoring will continue to grow (as
indicated by [a recent] Cutter survey). Apparently, this elephant will be around for
quite a while.
"IT Offshore Outsourcing: The Elephant in the
Room"
Sourcing & Vendor Relationships Executive Summary, Vol. 6, No.
11
by Curt Hall
A key concern with any scorecarding or business performance management application
is getting access to the data required to support the system. Obviously, requirements
will vary according to application and company needs. But based on surveys of
end-user organizations as well as discussions I've had with business performance
management practitioners, I have determined that companies should plan on integrating
approximately 10 to 15 data sources in order to adequately support a business
performance management initiative. Less comprehensive or encompassing scorecards and
dashboard applications (i.e., designed to support a few processes or business
activities) will probably require integrating fewer data sources.
"Interest in Dashboards and Scorecards Continues to
Accelerate"
Business Intelligence E-Mail Advisor, 8 November 2005
by Bartosz
Kiepuszewski
Even considering that most artifacts related to business architecture (business
goals and objectives, organization structure, etc.) should already be defined and the
architecture team could simply collect them, taking responsibility for analysis and
definition of business processes could prove to be very tricky. My view is that if IT
does not want to take seriously at least some responsibility for the business, it is
simply not possible to develop a good-quality business architecture.
"Who Should Take Responsibility for Business
Architecture?"
Enterprise Architecture E-Mail Advisor, 7 December 2005
by Robert N. Charette
The late management theorist Peter Drucker wrote in his classic 1986 book
Innovation and Entrepreneurship that past mistakes are fertile ground for
creating valuable future business. For instance, by examining in depth the reasons
for failure of the Edsel -- still synonymous for the ultimate in corporate mistakes
-- Ford was able to develop the Thunderbird, one of the all-time classic cars. If
past decisions are off limits to talk about, then no one should be surprised that
known but unspoken risks turn into major corporate surprises. By being able to look
honestly at its past, an organization is able to look realistically at both its
present direction and its likely future possibilities. Further, it is better
positioned both for taking intelligent risks and creating an organizational
atmosphere where innovation can truly flourish.
"Admitting Mistakes"
Enterprise Risk Management & Governance E-Mail Advisor, 1 December
2005
by Steve Andriole
There are all kinds of business criteria that should be evaluated prior to a merger
or acquisition. Some of the more obvious ones include synergism among the business
models, cultures, and processes. But there are also many technology criteria that
speak directly to how easy or difficult it will be to integrate and optimize the
technology of the companies in question. If the technology infrastructure,
architecture, and applications are incompatible, there will be serious -- and
expensive -- problems with integration and optimization. There are also philosophical
issues to assess. How is technology acquired? What sourcing deals are in place? How
is technology organized? To whom do the technology leaders report?
The problems -- as always -- are part technical, part organizational, and part
human. For years our industry has distinguished among "people," "process," and
"technology" criteria; M&A due diligence should include these -- and additional
-- factors.
Formal M&A due diligence efforts require a framework for organizing and
assessing the due diligence criteria that matter. The framework should include
criteria that address all aspects of the technology environment, and it should also
accommodate criteria weighting, among other methodological capabilities.
"M&A Technology Due Diligence: A Framework for
Assessing the Good, the Bad, and the Ugly"
Cutter IT Journal, Vol. 18, No. 10
by Jim Highsmith
In a well-functioning agile project, customers prioritize work and developers
estimate work and the impact of change. Furthermore, in an agile project, the project
community -- customers, managers, and developers -- jointly own the results of the
project. They all have to understand the vision for the product, the scope and
boundaries of the project, the business objectives of the project, and they jointly
own the plan and changes to the plan. They understand that responding to changing
business or competitor events means changes in the project plan that every member of
the project community must buy into. Without this common acceptance of goals, plans,
and alterations to the plans, there is a lot of finger pointing, such as, "You didn't
meet the plan (a conformance to plan mentality)." Accepting that success is a joint
responsibility leads to a conformance to acceptable results mentality, one in which
the plan changes, sometimes dramatically, from the original but the revised plan is
acceptable to all parties and therefore becomes the new measure of success. In this
scenario, customers and management realize that they are as responsible for the
project's success as the development team.
"Scope Creep or Responding to Business Change"
Agile Software Development & Project Management E-Mail Advisor, 23
November 2005
by Helen Pukszta
One of the hallmarks of organizational IT intelligence is adaptability to newness,
in its many forms. It is adaptability to changes in the IT environment outside the
enterprise: new technologies to consider; new consumer gadgets to watch; new
competitive uses of IT to monitor. And it is adaptability to changes driven by
IT-based initiatives inside the enterprise: new technologies to learn and implement;
new resources to gather and apply; new processes to design and adopt. In their
adaptability to changing IT needs and environments, organizations must make choices
about what to hold constant and repeatable and what to continually change and adapt.
Finally, IT-intelligent organizations also have adaptability built into their IT
architectures and infrastructures (though still not of the artificial intelligence
kind). As the dot-com era has taught us, anyone can invest in IT. But it is those
organizations with significant IT intelligence that can do it faster, better, or
cheaper, or in a way more tightly integrated with their strategies. And doing any of
those repeatedly over time can set a business apart from those who just invest. What
is required is clear thinking and sound judgment in complex business-IT matters. The
obvious starting point is to hire managers and executives who are both business- and
IT-smart.
"What Is Your Organization's IT Intelligence?"
Business-IT Strategies Executive Report, Vol. 8, No. 22
by Jeffrey Kaplan
The IT industry is notorious for promoting new technologies with limited real-world
value in search of a market. At the same time, there have been many worthwhile
innovations that have failed to win widespread industry acceptance because they
couldn't be easily adopted. Software-as-a-service (SaaS) isn't just another IT fad
that will fade away because it doesn't fulfill its promise. Instead, there are a
growing number of enterprises of all sizes that are generating measurable cost
savings and performance improvements as a result of adopting SaaS. This track record
of success is accelerating the rate of adoption and expanding the range of
applications that are being converted to the SaaS delivery model. It is also
dramatically changing the competitive landscape of viable SaaS providers. Relative
startups, such as Salesforce.com, RightNow, and others, are now viewed by customers
as equal or even superior to the far more established and historically more powerful
major ISVs, system vendors, and outsourcers. These trends should compel every
enterprise to reevaluate their software sourcing, deployment, and management
strategies. As SaaS alternatives become more pervasive, and their operational
reliability and cost-effectiveness become more obvious, IT decision makers that do
not pursue these options will be doing their enterprises a serious disservice.
"SaaS Survey Shows New Model Becoming
Mainstream"
Sourcing & Vendor Relationships Executive Update, Vol. 6, No.
21
by Curt Hall
Corporate BI tools standardization spending trends for 2005 and 2006 strongly
indicate that more companies have moved beyond the strategy and planning stages to
where they are actively carrying out their BI tools standardization and consolidation
initiatives. Based on the findings from this survey, I estimate that corporate
spending on BI tools standardization will experience a moderate increase in 2006. The
main reason spending on BI tools standardization will not enjoy a significant
increase in 2006 can be attributed to large companies, many of which have already
spent heavily in 2005 in carrying out their initiatives. As a result, spending by
large companies on BI tools standardization initiatives in 2006 will remain
approximately the same as it was in 2005. However, spending by large companies will
remain healthy all the same. On the other hand, spending by small and medium-sized
companies on BI tools standardization efforts is expected to increase considerably in
2006. This is understandable, since our survey indicates that small and medium-sized
companies were considerably farther behind the curve (compared to large companies) in
implementing their BI tools standardization initiatives in 2005. Finally, however, I
must express caution when it comes to company spending projections for BI tools
standardization efforts in 2006; they are obviously subject to change in today's
dynamic IT spending environment (particularly since 40% of companies were unsure of
their 2006 spending plans). Consequently, we will only know for certain once we have
conducted another survey measuring corporate BI tools standardization spending trends
in 2006.
"Corporate BI Tools Standardization: Spending
Trends"
Business Intelligence Executive Update, Vol. 5, No. 21
by Mike Rosen
[A] significant change that EA addresses is the inevitable introduction of new
technologies. One common approach to this is to clearly separate the logical aspects
of a design from the technical details of its implementation. This
"platform-independent design" technique is a manifestation of the common
architectural principle of separation of concerns and has been shown to greatly
reduce the cost of technology upgrades.
A second approach to accommodating technology changes, and particularly the
introduction of new technologies, also relies on separation of concerns. In this
case, the different architectural elements (components) of an application are
carefully designed to have well separated roles and responsibilities. When a new
technology comes along, only those aspects of the application that have overlapping
roles and responsibilities are affected. Good architectures can support multiple
different implementations of the same roles to simultaneously support multiple
technologies. For example, a well-designed Web application would separate the
concepts of device, presentation, local processing, and interaction. When a new kind
of device, like a smart phone, needs to be accommodated, the existing design is
simply extended to support the new devices. More importantly, the existing
application is not broken and the same business logic is used to support all types of
devices, providing consistent results to the user regardless of what device they use.
An important aspect of the application architecture specified by EA is t