E-MailArchived Quotes of the Day
Let us replace rapid delivery with early delivery. What does that change? Well, the state of mind changes from "let us deliver all this stuff right away" to "let us work toward getting all things done to deliver them at the earliest convenience." The emphasis on the first state of mind is time, whereas the emphasis on the second state of mind is completion. We know time is important anyway, so why focus on the obvious instead of on what is required to be able to have something to deliver? Thinking about our actions this way allows us to pay attention to the quality of our work and, in the end, delivery will be possible within reasonable time frames while reducing, if not eliminating, technical debt.
In a Semantic Web wonderland, we are each and all master -- master of our context, our language, our assertions and opinions -- all viewed through the individual looking-glass of our own personal semantics, influenced by the pragmatics of our experiences, memories, knowledge, and wisdom. In the aforementioned wonderland, we embrace diversity of opinion and differing reference contexts, and we find that absolute consensus is not a requirement to perform useful computing and infer meaning from the Semantic Web.
Adopting the social media philosophy may be your toughest challenge. You may encounter some Luddites who believe that social media's a fad that will be gone in a few years. There's not much you can do about this attitude if it's held by those in charge, except perhaps wait them out. They might change their minds, move on, or retire. Behaviorally, the challenge is about openness, sharing, collaboration, and, to some extent, antiprivacy. Technologically social media requires a commitment to a technology architecture and delivery model that works for your company.
In many instances, clients will come to our doorsteps with offers that seem too good to be true. It's a major undertaking but we, organizationally, are just the folks to make it happen. And besides, it's got a jackpot payoff!
The problem that exists is that there's often an enormous disconnect between the people making the decisions and the folks who will ultimately be responsible for making the work happen. And that's a gap that needs to be bridged before we get in line for the next great opportunity. The connection is not a hard one to make, but it's one that has to exist in order to truly know if we're picking up a "winning ticket." The three tests that need to exist are:
Are the work assumptions captured?
Did someone who does the work look at the deal?
Does the deal account for the range of possibilities?
If we haven't confirmed a "yes" answer to these three questions, then we should probably reconsider investing in the latest version of organizational lotto.
"The Lotto Temptation" Business-IT Strategies E-Mail Advisor, 23 June 2010
Even for those disciplines that share a common and well-understood vocabulary, the act of configuring a system requires that one understands the use to which the information will be put. For example, the call-center discipline can have a clear definition of a "customer," but if its customer information needs to be communicated in a legal proceeding, the definition of a "customer" could require simple or even significant alteration. The utility of information lies in its use, and here pragmatics matter greatly. All information, I contend, has this dual nature of pragmatics and semantics. As information gets diffused, how the computer handles pragmatics grows in importance. Why? So the computer can do more and we (theoretically anyway) can do less. Google's ability to know your location (context) helps it narrow down the choices as it interprets what address you typed in (semantics). Knowing how metrics are going to be used (pragmatics) in a business intelligence solution affects how the metrics will be constructed (semantics).
Teams of people capable of working as an ensemble have a lot to offer: they are extremely adept at responding to shifting contexts -- things like new information, new resource constraints or commercial opportunities, customer feedback, even shifting team membership -- and incorporating these factors into their work; turning constraints into sources of ideas and inspiration. Because the work of an ensemble is highly interdependent and their actions emerge from the collective context, the outcomes they produce have a high degree of coherence. This approach differs from achieving coherence because everyone agreed up front what the outcome should be. It allows for heterogeneous perspectives, creative conflicts, and the trial of many seemingly conflicting ideas to reach the best outcome -- "best" because it is most suitable to the context.
When speaking to new enterprise architects, I tell them to visualize hundreds of systems with thousands of programs operating on tens of thousands of data tables. Visualize large chunks of all of this with poor or no documentation -- forget building architecture; think city planning. Visualize thousands of interfaces from internal system to internal system, from internal system to business user, and from internal system to external system -- forget building architecture; think transportation planning.
"Draining an IT Swamp Calls for EA Vision," Enterprise Architecture E-Mail Advisor, 16 June 2010
Looking at the disasters of late, it seems that many companies and governments have made Faustian bargains, with unmanaged risk playing the role of the devil. For instance, a few weeks before the BP disaster, the US government approved the expanded offshore drilling of oil. The reason was that senior Obama administration officials -- including the president -- perceived deep-water oil rigs as highly unlikely sources of oil spills. Nothing had happened for 30 years, the rigs were seen as technologically advanced, and there was a belief that any spill could be contained quickly and easily; ipso facto, the risks were being well managed.
But as events have now shown, the risks involving deep-water oil drilling were only partially identified, and even those risks (and the ability to actively manage them let alone assess them correctly) were played down by both BP and the US government. Like the devil in Faust, BP and the US government wished for those 30 years of "good times" to last forever; the devil -- aka risks unmanaged -- is now claiming title to both souls.
The promoters of the software craftsmanship movement claim that programming is a skill that requires lifelong learning. They argue that you learn professional programming not only from a textbook, but also by collaborating with skilled peers. Of course, there are rules for good code, but building good code requires more than theoretical knowledge of these rules -- it requires tacit knowledge and experience. And this is where craft enters the scene: craftsmanship is the traditional means of teaching and transferring tacit knowledge and experience. So is this a battle cry against software engineering? Some people think so. Personally, I believe this is an artificial conflict driven by too narrow an idea of what engineering really means. Engineering means basing your work on scientific research. However, it does not mean basing your work exclusively on scientific research. Some of the highest-skilled professions are a mixture of scientific research and traditional craft. Take surgeons as an example. No one would ever think that a great surgeon would restrict herself to planning surgeries while allowing the plans to be executed offshore by staff selected on the basis of minimum hourly rate. So the discussion is not that much about neglecting the engineering part of software development but about promoting those aspects that have been neglected to this point.
"Software Programming as Craft: The Impact of Agile Development," Cutter IT Journal, Vol. 23, No. 4
Why do we embrace agility in the first place? Agility helps us manage change and uncertainty. Turbulence -- business, economic, and technological -- creates change, which in turn creates both opportunity and peril. Change does not yield to rational analysis; responding to change requires a leap of faith. Sure, one can analyze the situation and come up with options that look reasonable, but most of the time, significant changes create mounds of uncertainty, and the decisions required to respond to those changes are never clear-cut. There is never one obvious option, but a multitude of options that seem reasonable. There is never enough information, and the information in hand is often contradictory. Change creates ambiguity, uncertainty, doubt, and indecision that lead to floundering.
Agile leaders have the ability to cleave through this ambiguity, to focus on a decision when everyone else is floundering, to clarify direction when everyone else sees confusion. This requires an ample supply of thought and analysis, but probably an even greater supply of guts. Providing focus and clarity is both mentally and emotionally taxing. Agile leaders have doubts, just like everyone else, but they can put these aside in order to drive the project or the organization in the right direction. They can communicate the decision, focus, and clarity to others.
And, they can change that direction if need be.
To achieve fuller benefits, an enterprise green IT strategy has to be well defined, comprehensive, consistent, and holistic, and green measures have to be governed at the strategic level, managed at the tactical level, and practiced at the operational level. In many cases, it is appropriate and even desirable to take a phased, incremental approach to implementation, as it can make execution/implementation easier and obviate the need for large investment for enterprise greening efforts. Also, enterprises have to create and foster an enterprise-wide green culture and make green awareness and considerations a cultural trait.
Nothing communicates just how much we all live in the same world as something like pollution of one of the world's major waterways or the air we breathe. Just recently a natural disaster -- a volcano in Iceland -- disrupted not only air traffic over Europe but also the air quality for millions of people. It will be difficult for those of us living today to stop thinking of nature as a place into which we can depose of things that we want to get rid of. We and our children are going to have to be increasingly environmentally conscious. Even if we start now, it will be decades before we can make a difference.
Those of us in the computer software business must learn to be environmentally conscious in multiple ways. We will have to think about how we develop our own products and how we use our tools to help our organizations and countries become safer and healthier. To that end, we are going to have to rethink how we develop software and how we maintain it over very long periods of time.
Puzzles have answers. Railroad crossing: look out for the cars. Can you spell that without any Rs? Yes: t, h, a, t.
Problems have solutions. What's five times five? How can we send some men to the moon? Problems can be simple (five times five) or complex (a man on the moon), easy (five times five) or difficult (a man on the moon). But we can solve them.
Difficulties have no answers and can't be solved. We may mitigate, even surmount them, but mostly we can only address them.
It's not rocket science to see that in politics, most of the situations we call problems are in fact difficulties. It's also evident on a moment's thought that mistaking one for the other will cause no end of trouble. When we refuse to acknowledge a difficulty and instead call it a problem, we raise expectations that must be disappointed. Politicians love to do this, of course. So do managers. But as Edwards Deming pointed out again and again, calling quality control a problem and attempting to solve it gets us nowhere. In fact, it quite reliably makes things worse. When industrial firms stopped trying to solve the quality-control problem and adopted Deming's statistical methods of addressing the quality-control difficulty, things got better.
"The Problem of Difficulty," Innovation & Enterprise Agility E-Mail Advisor, 27 May 2010
While better communications will help to make a design review go more smoothly, the best approach is to work with the development team during the design process itself to help it factor in the architectural and other enterprise requirements. Be careful to respect boundaries. Architects provide a set of requirements and help bridge the gap between project goals and enterprise goals. But it is not the architects' responsibility to design the solution or to "tell developers how to write code." You can have an opinion, but you don't necessarily have to like the solution as long as the requirements are met. Collaborating with development will enable the team to understand the bigger picture and the overall tradeoffs, and help to avoid the situation where implementation is already underway and it's too late to make changes to the design. It's always better to head off a bad design then to have to grant an exception after the design review.
The application of green IT initiatives is increasingly becoming seen as a corporate social responsibility that enterprise organizations are being judged against. While not yet a major issue in the US, in other parts of the world, customers and governments are beginning to hold positive or negative views of companies and their products or services based on how “green” those companies are in producing, distributing, and offering those products or services. Green IT is merely an extension of this association.
A company that appears to take an environmentally sound approach to its full range of business activities -- including the use of IT -- is seen as being socially and ethically responsible, with resulting enhancement of its reputation. The converse is also true.
Examining the responsibilities of a contextual craftsman, we can see that they don't strictly require an agile methodology. Nevertheless, an agile environment embraces contextual craftsmanship and makes it explicit. Agile methods demand (and make transparent any lack of) craftsmanship in design, coding, and architecture.
As the widespread adoption of agile methods brings all sorts of truths to the surface, craftsmanship adds a dimension of professionalism that was always implicit and rarely truly discussed. With more and more companies realizing that technical excellence and discipline are vital for continued success (agile project management isn't enough), the benefits, challenges, and limits of craftsmanship will surely be tested.
"Today's Business World Needs Contextual Craftsmanship," Cutter IT Journal, Vol. 23, No. 4
Some draw the conclusion that you must use agile exactly like it is written in the books; otherwise, it won't work. Well, that is at least a better start than using only some of the practices and ignoring others that may form the foundation of those you have chosen. Doing refactoring without test-automization is like doing surgery without hygiene. On the other hand, the books are only the essence of the experience the authors have made in their context. Your context may not match with theirs and they have additional experience that may not have made it into the book. Some of it may have been left out consciously to keep the book on focus; some of it may have been left out unconsciously because it is just tacit knowledge that the authors are not aware of themselves. You need a lot of experience to really form an agile team. "Scrum is simple to describe, but hard to implement," one of my clients once wrote in his presentation. Likewise, you could say, it is easy to read notes (at least if you don't have to do it in real time), but hard to become a professional musician. And you probably won't become a master musician by distributing one sheet of notes to your team and tell them to play it.
"Pitfalls of Agile VI: Simplicity," Agile Product & Project Management E-Mail Advisor, 10 June 2010
As is well known, IT has fundamentally altered our work and life and contributed significantly improving the productivity, economy, and social well-being of people. Moving ahead, IT now has an important role to play in creating a greener, sustainable environment and in offering environmental benefits. To realize the fuller potential of IT in addressing its environmental problems through reduction of its carbon footprint, each enterprise must develop a holistic, comprehensive, realistic, and relevant green IT strategy, and it should form a component of and be aligned with an overall enterprise’s business strategy.
In the early days, security was an afterthought. Security meant having to have a password to get onto your computer. But once the Internet exploded and the world discovered viruses and all matter of malware, security became a major problem. As much as the world has spent on computer security, however, the security problem has only gotten worse, as malware developers and spammers have become more and more sophisticated. Increasingly, the software security industry has existed to fix one hole after another.
As a result, computer security has become a bigger and bigger business. The most common approaches to security have been to create operating systems and Internet browsers with various levels of firewalls and to develop larger and larger anti-virus programs that, as soon as one new virus or method of attack popped up, antivirus was quickly developed to detect and isolate it. That approach, which is roughly equivalent to the method used by the Dutch boy who stuck his finger in the dike, has mostly worked. In the process, however, virus programs have gotten bigger and bigger, and more and more time has been spent downloading and installing the nightly virus downloads -- a tax paid by the entire computer industry and all of its users.
EA today is very different from what the founders of EA imagined. It's a moving target that needs to adjust its roots to the new realities of technology acquisition, deployment, and support. While EA remains a laudable goal, it's difficult to get your arms around it. Perhaps it should remain as a conceptual goal that may or may not realize its full form, and maybe that's just fine. Is this a case of "the perfect is the enemy of the good," as Voltaire said? It may well be. A commitment to EA is a lifelong pursuit of an ever-changing target. While there will be many who suggest that the principles of EA will withstand all of the changes in technology and especially the models of technology delivery, others will suggest that EA needs to adjust its focus and objectives to accommodate how the world's changing. You decide.
How can you be sure that you are meeting all regulatory requirements and your company's data is secured? Relying only on the results of annual audits can be deceiving, even when the results indicate few issues. Keep in mind that a compliance audit shows a point-in-time status. Your organization undergoes changes daily, whether it is a new employee, a process change, or an implementation of new hardware or software. While change is inevitable, it makes it very difficult to maintain a compliant environment. So becoming compliant and sustaining compliance are the challenges.
A centralized technology compliance office (TCO) can improve your organization's chances of obtaining and sustaining compliance -- and reduce the risk of possible data breaches. Take a moment to evaluate how your organization manages compliance and how to improve its effectiveness as a front line of defense for regulatory requirements and corporate data and information security.
I was recently interviewed for CIO magazine as part of an article promoting "green" values and confirming sustainability claims by IT hardware vendors. Ten years ago that interview never happens, and yet the sustainability movement has been alive and well for many, many decades....
Affecting change doesn't happen simply because it is the right thing to do. It takes uncommon commitment. It occurs only when each of us draws the metaphorical line in the sand and says through our actions that we intend to light our lamp against the darkness; it is here we make our stand. The good news is that today it takes less time than ever before to mobilize economic forces to affect change. Causes that were difficult to jump-start have found traction thanks to e-mail, instant messaging, text, tweets, message groups, and social networks.... [F]rankly, just providing readers with links will prompt some to visit and others to get involved. Feels like a nascent trend to me.
"The Winds of Change Have Begun to Blow," Business Technology Trends & Impacts Council Opinion, Vol. 11, No. 1
Implementing green IT across the organization should be seen as a comprehensive business transformation effort that affects the entire organization and not just one or two of its parts. For example, the business leadership of the organization should prepare for changes to the business model as well as the product portfolio of a business as the business undertakes a greening effort. This change is akin to the change that occurs with any other technology-based business transformation. Therefore, another key message that emerges ... is that metrics and measurements play a significant role in the green transformation (which is a business transformation) of the organization.
Finally, green transformation also implies IT systems upgrades, use of emerging technologies, implementation and integration of CEMS, and changes to the organizational structure. This results in a related but large area of investigation that can be called environmental intelligence. Needless to say, further investigation and validation of green IT metrics is required.
In modern computing, all of our heroes are hackers -- loners who operate by their own set of rules and report only to their peers. But those of us in the business know that the vast majority of programmers work for someone, and moreover they work on predefined coding assignments with well-defined limits. CMM Level 4 or 5 organizations even prescribe how requirements, design, coding, and testing are done to a very low level. And even "agile development" prescribes that programmers work on very small increments, use test-driven approaches, and work in pairs, with each developer constantly checking the other's work.
Perhaps preferring software to be a craft is really a rebellion against the current dictates of the software industry. We suspect that a great deal of the "open software" movement -- despite its stringent peer-review requirements -- expresses the need of many developers who work as journeymen in these large organizations to be able to exercise freedom once in a while. Perhaps software is where all crafts arrive when craftsmen bump up against the stark realities of "industrialization." For the large number of programmers trapped in Dilbert-like cubicles working under strict rules and even stricter deadlines, a simpler, kinder world where software is a craft and programmers have more say in what they do is a common dream.
"Engineering: YES; Craft: NO," Cutter IT Journal, Vol. 23, No.
When I advise enterprises whose leaders are considering significant up-front investment in new or expanded data center capacity, I suggest that they would be remiss in not considering cloud computing solutions for all or part of their hosting strategy. At the minimum, playing the cloud card may realize additional leverage in negotiations with data center hardware and software vendors. In negotiating the best licensing deals for enterprise database management systems (DBMS) products and services, we used to play Microsoft, IBM, Oracle, and open source DBMS solutions against each other. Today, we can add cloud IaaS and PaaS solution providers to the competitive mix. Competition is a good thing; in this case, more is necessarily better!
Time Magazine, in its April 12 spread on Apple, says Apple doesn't ask people what they want; it tells them what they want. I disagree with that characterization. Chief designer Ive and his team, like any great creative philosophizer, infers what people need in ways that other philosophers can't. The iPad, like many of its Apple predecessors, is a product of tacit and intangible team creativity. Ive and his team focus intensely on the utmost simplicity of the user experience, until the design fades into the background enough that it merges with the use. They don't use any real methodology that other product design firms do. They use their teamwork and intelligence almost exclusively. This makes it very hard for competitors to copy and is the reason that the iPad is, so far, what it appears to be and why Apple has been on a 10-year roll.
Where Apple has rushed in, fools, beggars, and fierce competitors will now tread. The competition will heat up, no doubt, and there is no guarantee that Apple will remain ahead. But I have seen the future of ubiquitous computing and it looks very much like the iPad.
Following [Miles] Davis's example, leaders capable of accomplishing presence -- deep listening and attentiveness -- are well positioned within their organizations to direct the focus or center of gravity, modify the intensity of the work, and invite individuals to take the lead.
Furthermore, leaders can open a space for play. Innovation leaders know we become (more than we are) when we practice, that we know by doing. Davis opens space for other musicians to play -- to exhibit their talents and ideas -- by listening to their choices and responding to what delights him, encouraging further exploration. Experience is never enough, and is sometimes a hindrance, when imagining, sensing the "nextness" of what needs to be created, or finding the right tune. Agility serves the ambidextrous: being a responsive, adaptive character oneself, the agile one responds to the rhythm, sound, and style of the many. Davis acknowledges this by letting the event unfold and encouraging agility in terms of passing leadership and the possibility that the focus will move at any moment. In this way, he allows opportunity for "ensemble" -- the ability to act as one coherent responsive entity, greater than the sum of its parts -- to grace the collective with its presence like an event, bestowed upon those who have earned it. At that point, there is neither one (leader) nor many (group), just sweet music.
Many leaders are enticed to engage in an agile methodology, such as Scrum, XP, FDD, TDD, DSDM, and lean, because there seems to be an implicit promise of faster, better, and cheaper results. The gathering together of teams of technical- and business-minded people to do something better than they ever have before is not only a promise, but an expectation of the Agile Manifesto. However, what may not be so clear is that leaders can't just plug in the new methodology and expect the firm to perform miracles on its own. Rather, they must be enrolled personally in the philosophy and be fully engaged in the daily process of culture change to assure the agile miracle occurs.
Yes, the Internet changes everything. But, the more things change, the more they remain the same. Without reliability, availability, performance, and security, new capabilities can't be used for business-critical activities. So, make sure you understand how a SaaS solution fits within the complete, end-to-end application requirements, and make sure you have accounted for reasonable user expectations when evaluating cloud solutions.
We have seen that software development organizations are globally expanding their development teams, and that alone strongly suggests that software teams are becoming flat. But there is more.
We have also seen that teams are affected by the steady growth in agility. Fueling this trend is the increasing demand for consumer software coupled with the growing reliance on infrastructure software, such as financial and communications applications. This expanding demand for software is a global phenomenon, resulting in an expanding need for more development resources, which in turn fuels the expansion of global development. And as Thomas Friedman, author of The World is Flat, has stated, communications technology is making it easier to fulfill that need from almost anywhere around the globe.
So, yes, indeed, software teams are becoming flat. As we have seen, team management practices are adapting to this new reality, and project managers must learn to manage dispersed teams using the new technology that is now available.
As important as success is to any organization, it's just as important to evaluate how we deal with the situations where the organizations don't succeed. That's truly crucial. But note how I framed it here. It's not about failure; it's about a lack of success. The two are not interchangeable. Failure is defined as both proving unsuccessful and nonperformance. The front half of the failure definition is there any time we don't succeed. The back half -- the nonperformance half -- is not. And that's something that we need to focus on strategically in order to optimize our decisions and to make better choices for the future.
"Coping with a Lack of Success," Business-IT Strategies E-Mail Advisor, 21 April 2010
From a technology perspective, predictive maintenance involves applying predictive analytics to analyze equipment reliability data. From a company/equipment maintenance perspective, it represents nothing less than the shift from periodic maintenance programs to predictive maintenance; in effect, allowing companies to perform "just-in-time" maintenance on equipment. The appeal is straightforward: periodic or planned maintenance can result in possible unnecessary replacement of equipment and components. Failure to carry out needed maintenance on time can result in equipment breakdowns, which can affect overall operation and/or availability of key resources (think of a process or manufacturing line shutdown or a vehicle or weapons system out of service, etc.).
"Mining Data to Predict Equipment Failure," Business Intelligence E-Mail Advisor, 4 May 2010
IT work is performance work and can be measured (although often with difficulty). Individual skills, ability, and attitude matter greatly. IT unit productivity is utterly dependent on smart people working quickly as a team. IT units that can’t figure out how to identify individual and team weaknesses are doomed to mediocrity at best. IT units that can identify weaknesses but can’t figure out a way to address them without demoralizing people also face the same fate. Performance review dysfunctions can transform potentially vibrant IT shops into zombie land. Walking dead roam the halls, numb to feedback, unresponsive to either carrots or sticks, inadvertently and silently terrorizing.
I disagree with the premise that prosperity breeds innovation and scarcity kills it. People innovate when there is a need to find a new or better way to do something. The decline in our economy has created a tremendous need for everyone to find innovative ways to prosper with less. The ability to innovate is not directly proportional to the size of the budget in business or in our personal world. In fact, I propose that the two are indirectly proportional in many cases. If an IT organization were to adopt the attitude that it cannot innovate because the business is in trouble, there is little hope for its future and, more than likely, its company's future. I cannot imagine any corporate function going into a "treading water" state in times like these. Granted, the innovation game and the goals have changed during this past year; however, the innovation game is still being played in those companies that desire to survive.
I have come to firmly believe that the best results, at least in the strategic application of IT, emerge when the IT group serves as the fulcrum and hub for the design and development of the initiative. It is in these cases that IT -- the ultimately malleable resource -- can find cross-functional uses and learning can quickly be generalized across problem and opportunity areas. As I said many times, it is ultimately up to IS professionals, with their understanding of both technology and business, to captain Web 2.0 initiatives.
"Web 2.0: Buzz and Hype Subside, and the Real World Begins," Cutter Benchmark Review, Vol. 10, No. 3
[I]n the end it is not the process but the product that counts (though the process does count for quite a lot). This is an especially important lesson for those working to helping their enterprises develop a "business architecture" (think assembly line brought into the 21st century). Increasingly, business architects are coming to recognize that they need to really understand their company's business processes and that ultimately those business processes are ultimately about producing quality products and services. Technology, business rules, and services are all important to business architecture, but are only a tiny part of the picture. Business architects have to be passionately interested in "the business," "the product," "the market," "the customer," and "the employee" as well.
When expressed in $$ terms, technical debt ties neatly into value vis-à-vis cost considerations. For a "well behaved" software project, the three factors -- value, cost, and technical debt -- have to satisfy the following equation:
Value >> Cost > Technical Debt
The failure of a project to satisfy this equation for a period of time is an early warning sign that the project might be in trouble. Either the design/coding/testing of the software leaves much to be desired, or the software being developed is not affordable in the long run (given the revenue forecast), or both. Monitoring the balance between the three factors (value, cost, and technical debt) on an ongoing basis is an effective way for staying on top of the real progress a project is making and for taking remedial steps at a point in time they are most effective.
Everyone knows estimating work in IT can be difficult.
Whenever you ask an IT expert for an estimate, the sequence of events can look like this:
- Requester asks, "How long do you think that will take?"
- The expert pauses, silent, eyes looking up. You can see the wheels spinning.
- After a few moments, the expert responds: "It depends."
- The expert and the requester begin a new round of conversations, further specifying what "it" is and what "depends" means.
Estimating isn't really estimating at all. It is a process of understanding with greater specificity, breaking the work down in greater detail and nailing down unstated or less clear choices. Once all the details are known and can be easily related in the mind of the estimator to work done in the past, the expert can give some estimates. The key challenge for estimators is that requesters often want estimates without needing to go through the extra specification. What is the right balance between accuracy of an estimate and the speed at which the estimate is delivered?
The journey toward real-time anything and everything began decades ago. Since the very first algorithm fired in a clunky mainframe, managers and executives dreamed of the day when they could immediately answer any question that came to mind with their digital technology. Some even dreamed of ultra real-time processing, where answers could be acquired from questions yet to be asked! But most of us, back in the day, would have been overjoyed with near-real-time processing or what we used to call "approximate-time processing."
The assumption has always been that real-time (or near-real-time) processing would yield more competitive decision making. While the assumption is sound, near-real-time processing and decision making would do very nicely for the vast majority of managers and executives.
The power of today's (hardware and software) architectures is about to deliver near-real-time and even real-time processing. The challenge is to optimize the intersection of architectures and requirements. It may be that you don't need to invest in real-time processing because you don't need to make real-time decisions. As always, there will be a hierarchy of capabilities and costs that determine your BI investment strategy.
[T]here are a number of places where the idea of capability levels can be extremely valuable for both IT and business managers, and that is in helping organizations understand where they are and what they should be concentrating on to improve. While most of the discussion of CMM has been on attaining the highest levels, my belief is that the most benefit is likely to come from focusing on improvements of the lowest/lower-performing units. These areas are often ignored because just getting people to show up, stand in line, do design before coding, and test what you develop is not glamorous, breakthrough kind of work -- but it is really important and can dramatically improve an organization's performance and agility. In the next Trends Advisor, I will discuss how organizations can use a form of CMM-lite framework to do a much better job managing IT.
Whether or not you think it has anything to do with global climate change, you have to admit that the weather this winter has been different and dramatic. At one point in February, there was snow on the ground in 40 of the 50 US states, with 1,180 new snowfall records set across the US. Virginia had received more snow than Vermont. Snow had snarled commuters, travelers, and shipping nationwide. But you probably already know about this, since one storm or another affected almost every American this winter.
Sure, your company has disaster recovery and business continuity plans in place for major failures and disasters. You're covered if the data center goes down, but how about when none of your workers can make it to the office? What is the cost of one, two, three days or more of nobody minding the shop? Are your infrastructure and systems ready to provide an alternative?
"Be Ready for Any Disruption," Enterprise Architecture E-Mail Advisor, 10 March 2010
Yes, we need managers. And in a truly agile organization, where the managers are freed from the day-to-day tactical project tasks, we need them more than ever as organizational leaders: setting strategy, managing the project portfolio, removing organizational obstacles, building trusting relationships with technical staff, coaching, providing feedback, assisting with career development, leading the hiring decisions and process, and building the capacity of the organization.
Technical leads, project leaders, ScrumMasters, program managers -- whomever it is that facilitates the project team's or set of project teams' work -- cannot perform all those functions. In fact, it's not a good idea for people who manage a project to both manage the people and participate on a project. Project work is tactical. Management work is strategic. In an agile organization, managers have the opportunity to be strategic; the never-ending project risks, issues, and problems do not distract them. Attempting to mix the tactical and strategic work means the person will only pay attention to one kind of work. Most often, that work is the tactical work.
"Agile Managers: The Essence of Leadership," Cutter IT Journal, Vol. 23, No. 3
[T]hree weeks ago, I attended a talk by a Team Software Process/Personal Software Process (TSP/PSP) expert and asked him whether it is possible to achieve better performance without the need for all of those statistics and charts. His answer was that it is possible, and that the path of the heavy process, stats, and charts was necessary to create the discipline. Once the team was up to speed, he said, it is possible to put aside the graphics and statistics. That made me grin because the same results can be achieved going agile; only it takes less time, money, and process.
Why take the expensive and long path to the same result? Some executives believe that an expensive and fancy software tool is more effective than a messy-looking Post-it-filled wall (or an automated tool that does the same thing), and that exhaustive data over an accurate pattern is necessary to make decisions. This is definitely good for the heavy-tool vendor but what is the real advantage to the enterprise? After that last meeting, as I was walking out of the office, I saw the director at his desk mesmerized by the charts on the screen while the developers were sitting alone at their cubicles quietly coding away.
We must get past the notion that cloud computing is to be a passing fad, failing to achieve mainstream adoption. In my opinion, cloud is as inevitable for computing as was large-scale electric-power generation, transmission, and distribution in the early days of the grid.... As a former IT executive in the electric utility sector, I observe with fascination the continued developments in mass improvement and efficiency as electric "smart grid" technologies come to fruition and that more regulated utilities are now required to buy back excess, consumer- or cooperative-generated power from the grid in a model known as "net metering."
The promise of business intelligence (BI 1.0) is finally turning the performance corner. While we're still cleaning, migrating, and securing data -- and worrying about platform compatibility -- we've also connected BI to business performance management, a step that reflects rising expectations about what the BI endgame looks like. We've also begun the journey toward structured/unstructured data integration/interpretation and real-time analytics -- as well as semantic processing, in anticipation of Web 3.0. Almost all of the major BI players have found new homes. All systems are go. The next generation of business intelligence (BI 2.0) is real -- and ready.
The courageous contributors to the Rugged Software Manifesto are tackling the tragedy of bad software by calling for a new sense of personal responsibility on the part of developers. This is the beginning of a new professionalism for the software industry. We often talk about software engineering but, until now, have not had rigorous engineering standards. In the real engineering world, critical projects require an engineer with a PE -- Professional Engineering certification, which requires intense study and demonstrated practice. The drive to certifying real engineering competence can be traced to disasters such as the Tacoma-Narrows Bridge collapse. The Heartland data breach and the violation of classified Pentagon data are equally appalling -- the equivalent of IT malpractice. Finally, through the Rugged Software Manifesto, some IT professionals have taken a stand against sloppy software engineering.
Perhaps the easiest, most inviting candidate opportunity for introducing the cloud in large enterprises is in BI and data warehousing. The cloud offers a mechanism of integrating data from worldwide resources into integrated data warehousing environments where the massive power of cloud resources on huge amounts of real-time, internal, and external data. Enterprise architects need to understand opportunities and apply their abilities to "think broader and longer" and imagine new classes of applications that can leverage existing data with new ways of processing, analyzing, and visualizing information.
Culture plays an important role in how managers lead and how employees follow (or lead within their specific area). The culture of an organization is more than just the values, vision, goals, and strategies. It is more than a PowerPoint or a framed poster in the lobby. Culture can be defined as the "story" of the organization -- the words employees use to describe where and how they work to friends and family. How does an organization define and align the culture? If it is misaligned, how can it be improved to have a more positive impact on employees' work and the service provided to the customer?
As we explore these questions, we need to understand the attributes of the various leadership levels: CIO/executive, director, midlevel, frontline. While executives need to cast a vision and perhaps view success across a longer timeline, the midlevel and frontline managers must be able to turn that vision into real-time tactics that drive projects at the activity and task level. In many cases, these managers were chosen to lead because they were good at getting things done -- not because they understand the nuances of leading people or setting strategies.
"Cultivating Leadership Throughout the IT Organization," Cutter IT Journal, Vol. 23, No. 3
The mantra of a productivity-centered goal could be "do more with less." The mantra of a value-centered goal could be "create value early." Productivity-centered goals belong in manufacturing where the process is unvarying and the inputs are known. Knowledge work demands a new set of goals, a new focus: knowing what is the most valuable. Knowing what to eliminate. Knowing when to quit. Knowing when to adapt. We won't overcome the "takes too long, costs too much" perception without looking at software development through different measurement glasses.
Data ownership is often a pernicious weed. If someone takes the mantle of data ownership to the fullest, he or she typically serves as strong fence builders and gatekeepers, keeping others out of their data garden. Owning information, the people believe, is the key to maintaining power, or these days, at least to holding onto a job. The problem is that data is like water flowing through pipes in a manufacturing business. It comes from a source, goes through many rooms where many people benefit, flows through the manufacturing floor where water may be needed, is combined with many other ingredients, and is impossible to own. If we replaced the term "owner" with "steward," we might make a small step in redirecting the ownership impulse in people. Let's take the term "data steward" as an example. Being a data steward comes with a responsibility to properly engage governance processes, to care for a portion of the lifecycle of data, and to provide value to the data. Since many people touch data, from initial data entry to data augmentation to front-line operational reporting to deeper analytics and data quality control, a data steward has to organize, communicate, collaborate, and foster communal decisions.
"Stewardship, Not Ownership," Business-IT Strategies E-Mail Advisor, 17 March 2010
When you make a new thing using a collaborative iteration process, you encounter the question of closure at each iteration. And, of course, you have to decide when you've got what you need or what they want, and make a choice when to quit altogether. Since the thing has emerged brand new, you get little or no help from outside: you must make these choices on the basis of 1) aesthetic coherence in the thing itself, and, 2) your best guess about its potential as a useful product.
This introduces you to a kind of doublethink common to artists in their work. To make a painting or a play, the maker or makers must consider the purpose of their efforts: Why am I making this thing in the first place? Any unique thing has a double purpose that guides its makers: 1) to be perfect of its kind, and, 2) to perform successfully the task for which it is designed. Does that look familiar? Yes: it's the grounds for the choice you have when you think about closure. The doublethink attacks when you realize that, while you sure want to make a useful, thus saleable thing, you can't put too much attention on that or it will distort the thing and interfere with its need to become perfect of its kind.
In some ways, with differences in scale, scope, and degree of control, an economic crisis is just like an IT security crisis. The last topic in my required IS class is on IT security and risk management. In that class, we discuss a real case where a firm with sensitive customer data is under a denial-of-service attack. The case enables students to gain a number of insights, none greater than the notion that the options available to the firm during the attack are a direct function of the preparation that occurred prior to the intrusion and ensuing crisis. In similar fashion, the set of options and opportunities to influence decisions during economic difficulties stem from your ability as an IT leader to create the appropriate context before there is a need for action.
A customer wants the product to have the value he or she is paying for and expecting. Oh wait, did I write value? If that is true, then how come value isn't considered as a project estimate? How many customer complaints do we hear because a product wasn't available by a set date compared to the number of complaints due to the quality of a product? Customers are much more willing to wait a little longer if what they get is a killer product. This means quality is more important to them. Last, let's say there are two products that offer the same value and quality to customers, which will sell more? The cooler one! This means design is also of high importance to customers.
Enterprises shouldn't use time, budget, and scope as a way to measure project success. They should focus on value, quality, and design.
I would argue that there has been something of a sea change in corporate attitudes [toward data warehousing, BI, and analytics], with corporate leaders today increasingly seeing data warehousing and BI as strategic applications. They no longer view their data warehouses and BI environments as useful only for generating reports or for analysts to conduct research or exploratory analyses. Rather, in addition to such "old school" data analysis applications, organizations are increasingly utilizing analytics to drive and/or optimize a broad range of systems (both analytical and operational) -- everything from personalization, customer scoring, and basket analysis to fraud prevention, text analysis, and predictive analytics.
Real business processes, on the other hand, are not neatly hierarchical and/or vertical -- real business processes are fundamentally horizontal by their very nature. Most major business processes run across a number of organizational boundaries, often across multiple enterprises (think customer --> Amazon --> UPS --> customer). In this modern electronic/Internet world, processes may execute in milliseconds, but they may involve dozens of different organizations.
Unfortunately, while 21st-century processes have been growing in complexity, traveling from organizational unit to organizational unit, management thinking about these processes has not kept up. The VP of manufacturing and distribution is still in charge of manufacturing and distribution, while the VP of sales and service is involved in order entry, billing, installation, and service. And the VP of manufacturing is evaluated based on different goals than the VP of sales. One is measured on keeping costs down and the other is assessed on customer satisfaction.
In the end, "business process thinking" is all about the customer. In an important sense, serious business process thinking is a "search for the East Pole." Customers don't care how complex the process is that gets them the product or service they want; customers care about getting what they want quickly, with a minimum of delay or unneeded procedure.
Today, we face a combination of complicated and complex problems (sound like architecture?). The era of the master builder, where a single, brilliant leader can handle everything has come to an end. Complex scenarios require communications among expert participants. Under conditions of true complexity, where knowledge exceeds any individual and unpredictability is the norm, efforts to dictate solutions fail. To address this, we need two kinds of checklists: one that assures that stupid but critical stuff is not overlooked, and a second that assures people communicate, collaborate, and coordinate.
The most striking difference between EA in 2000 and in 2010 is how EA touches, and is touched by, so many other factors both inside and outside of traditional IT scope. EA in 2000 was about establishing connections between applications that needed to communicate. It was purely internal to IT and was about the technologies required for these connections. EA in 2010 is about integrating all the capabilities required to deliver business capabilities. It is still an IT function, but it is reaching out to the business, focusing on use cases derived from business process models. EA in 2020 should be jointly owned by the business and IT and involved in many non-IT decisions, such as acquisitions, sourcing, or reorganizations.
In organizations that take risk transparency to heart with a positive outcome in mind, there's high value in sharing information openly and freely across the echelons. Organizations that fail to share context, probability, and outcome have the potential to create a cloud of despair or concern without any positive effect. At that point, it becomes just too much bad news. Honesty and context give us the opportunity to leverage information about organizational threats to our collective advantage.
If CIOs want to survive into the future, they will need to think of their job in terms of reducing the information, control, and/or time-related risks of their organization's customers, and wherever necessary, to remind senior management that this is their primary job as well.
Luckily for CIOs, this is likely to happen naturally. Cutter Fellow Steven Andriole persuasively argues that technology has been "commoditized, consumerized -- and [has] left the building," as he cleverly states it. In other words, information that used to be under the purview of corporations and governments has been democratized, and as a result, consumers are now able to manage the root causes of their risks better than ever before without the need of corporations or governments. Overcoming the lack of information to make intelligent risk decisions, for instance, is much easier today because of the Internet and, more recently, the growth of social groups.
This means that corporations everywhere will need to work harder than ever to achieve Drucker's objective of creating a customer. They will have to provide much more value-added information to customers and/or focus their efforts on reducing their customers' control- or time-driven risks. Profit -- which, remember, is the payment for mitigating a customer's risks -- is going to be increasingly difficult to generate.
"Back to the Future: The Future Role of the CIO," Cutter IT Journal, Vol. 23, No. 1
If you believe in macro trends analysis, then the recent forecasts by investment bankers about the rise of the mobile Internet may generate the final nail in the 20th-century CIO's coffin -- and more than a few in the coffins of sitting CIOs today. Mobility by its very nature enables decentralization and shared governance among technology and business managers. CIOs are now expected to reduce technology costs as they improve the delivery of basic and strategic services. They're also expected to partner with their internal clients, their outside vendors, and all of the stakeholders in the company's business, including supply chain partners, alliance partners, channel partners, and everyone connected with e-business. The dwindling number of CIOs thriving today are the ones delivering increasingly effective services for less money and the ones delivering strategic impact through investments in applications, customer service, and innovation that help their companies make money, improve services, and develop new products and services to improve their competitive advantage.
Needless to say, it's nearly impossible to deliver both operational and strategic impact with decreasing budgets. Many CIOs are thus battling unrealistic expectations that will inevitably erode their credibility and, ultimately, their effectiveness. Given the economic times in which we live, many CIOs are -- perhaps unknowingly -- on a death march.
"Who's IT Gonna Be? CIOs Past, Present, and (Poof!) Future"
Cutter IT Journal, Vol. 23, No. 1
Let's step back a bit and think. In the last 20 years, the adoption of the mobile phone has grown from practically zero to become a global infestation. If it were a disease, it would be a catastrophic epidemic, or perhaps an extinction event.
In 263 BC, travelers from Sicily brought the sundial to Rome where the new tool could now be used to divide the day into equal parts, allowing for better synchronization of meetings, events, and, of course, restaurant openings. Some Romans of the day cursed the introduction of the sundial because it allowed the opening of public eateries at a specific time. Rather than relying on one's natural sense of hunger to eat, these ancient Luddites complained that Romans were thereafter slaves to a device. Interestingly, despite its somewhat rapid spread in Rome following its introduction in 263 BC, the sundial dates back to 1500 BC in Egypt.
The Luddite reaction to both technologies is identical: cursing the loss of ancient ways and the intrusion into culture and traditional behavior by a cursed device. The benefits of both devices are also clear: better synchronization, coordination, and collaboration among people.
Enterprise architects -- good enterprise architects -- have the ability to look at the entire organization and not become disoriented. They have the ability to see business processes that span not only divisional boundaries but enterprise boundaries as well. They always have an eye on the horizons -- the one in front of them that everyone wants to talk about and the one behind them that is keeping their organizations from moving into the future.
"Key Skills to EA's Kingdom"
Enterprise Architecture E-Mail Advisor, 3 February 2010
Many organizations believe they will be better served by taking on new applications and tools to solve problems that can readily be addressed within Word, Excel, or other fundamental applications, if those applications are fully exploited. The tragedy is that most organizations don't take the time to find out the full, robust nature of the tools they have before investing in new tools. To genuinely determine whether a "shovel" solution is the answer, it's important first to find out who in the organization really knows how to wield the tool. Most organizations have true mavens who actually flex the varied capabilities of the tools at their disposal. Those internal experts should be setting the bar to determine how much effort is really required in order to make the existing tool set achieve what we want it to achieve. Then, we can leverage their insights to ask ourselves whether or not we should actually stick to our existing array of applications or if we should step up to new, beefier applications.
The most obvious lesson is that global software development will likely continue to expand throughout the coming decade, and teams will continue to be, at least partially, invisible. As communications infrastructure continues to improve in leaps and bounds, the geographical distance will become less of a concern. However, problems related to culture, language, training, instruction, and other aspects of global team management will require newer and better solutions than those we have today. We can therefore expect a combination of new tools, techniques, and methodologies to become not just available but necessary.
Software development organizations will need to overcome the frustrations of dealing with other cultures and learn to appreciate the advantages of global development, mainly because these advantages will grow. Consequently, global organizations will need to gear up for intensive training of their teams at all locations as new methods and tools evolve.
What is important to realize is the ROI justification for a technology project is less about the hard numbers and more about the psychology of getting other people to buy into your point of view. Too often in technology we get caught up in the "gadget culture." We equate new and shiny with valuable and worthwhile. Let's face it; most of us who have gravitated to IT have done so because deep down we are technophiles. Getting technophiles to buy into a technology project isn't difficult and doesn't require an ROI justification. It just requires that we persuade other techies that the proposed project will be fun and exciting. In point of fact, many technology companies have in the past sold to CIOs purely on this basis: buy our product because it's great technology. In today's world, however, the techies rarely hold the purse strings (at least to the big projects). In order to get an organization to buy into a new technology project, we have to convince those stakeholders that the project is worthwhile. We have to get them to buy into the value of the project and persuade them that it's worth doing. Notice there is more implied to that "buy-in" than some spreadsheet, however detailed, that predicts a positive ROI for the project.
I'm hardly surprised that many [organizations] are still unsure about what sort of effort they should be putting into social media tracking and analysis. This sentiment spills over as well into the ... finding pertaining to 23% of respondents indicating that social media is "overrated." But while it's certainly easy to say that social media is "overhyped" (what new technology doesn't go through this stage?), does anyone really expect consumer use of social networking sites to decline this year? I have read that sites such as MySpace may lose users as they fall out of favor and/or as new sites appear. However, I'd be quite flabbergasted if overall use of social media in general didn't pick up considerably over the next 12 months. I'd also be very surprised if we don't witness quite a bit of uptake in the number of companies -- of all makes and sizes -- increasing their product marketing and PR efforts on social media sites this year.
A number of cause marketing themes are observed in the wild today. The most widely adopted (and it seems generically applicable to all types of companies) are related to environmental themes of green technology, sustainability, recycling, and conservation of energy or natural resources. Other themes center around targeted charitable initiatives related to support of disadvantaged communities, regions, segments of humanity, and wildlife preservation. Another powerful theme is in changing the world through democratized open access to (pick one) information, products, services, government, sustainable resources, renewable energy, healthcare, bandwidth, and so on. In the coming decade, we'll see new companies, perhaps some like Google, spurring new heights of innovation, creativity, altruism, and backed with a cause -- a cause that can be artfully and delicately balanced with customer acceptance and support for the reality of stunning corporate revenues.
In a tough economy, CEOs need to shift their focus. Project initiatives are scrutinized much more closely, and cautionary spending becomes the guideline for most companies. In tough financial times, they tend to want to go for "sure things" and minimize risk for their company. If projects don't help reduce cost or improve productivity, there is a good chance they don't get funded. In 2009, CEOs made these tough decisions. What this means to the IT organization is that supporting many of these decisions will be a primary focus in 2010.
"Cautious Optimism in an Uncertain Business Climate,"
Cutter Benchmark Review, Vol. 10, No. 1
The most striking difference between EA in 2000 and in 2010 is how EA touches, and is touched by, so many other factors both inside and outside of traditional IT scope. EA in 2000 was about establishing connections between applications that needed to communicate. It was purely internal to IT and was about the technologies required for these connections. EA in 2010 is about integrating all the capabilities required to deliver business capabilities. It is still an IT function, but it is reaching out to the business, focusing on use cases derived from business process models. EA in 2020 should be jointly owned by the business and IT and involved in many non-IT decisions, such as acquisitions, sourcing, or reorganizations.
In organizations that take risk transparency to heart with a positive outcome in mind, there's high value in sharing information openly and freely across the echelons. Organizations that fail to share context, probability, and outcome have the potential to create a cloud of despair or concern without any positive effect. At that point, it becomes just too much bad news. Honesty and context give us the opportunity to leverage information about organizational threats to our collective advantage.
If CIOs want to survive into the future, they will need to think of their job in terms of reducing the information, control, and/or time-related risks of their organization's customers, and wherever necessary, to remind senior management that this is their primary job as well.
Luckily for CIOs, this is likely to happen naturally. Cutter Fellow Steven Andriole persuasively argues that technology has been "commoditized, consumerized -- and [has] left the building," as he cleverly states it. In other words, information that used to be under the purview of corporations and governments has been democratized, and as a result, consumers are now able to manage the root causes of their risks better than ever before without the need of corporations or governments. Overcoming the lack of information to make intelligent risk decisions, for instance, is much easier today because of the Internet and, more recently, the growth of social groups.
This means that corporations everywhere will need to work harder than ever to achieve Drucker's objective of creating a customer. They will have to provide much more value-added information to customers and/or focus their efforts on reducing their customers' control- or time-driven risks. Profit -- which, remember, is the payment for mitigating a customer's risks -- is going to be increasingly difficult to generate.
"Back to the Future: The Future Role of the CIO,"
Cutter IT Journal, Vol. 23, No. 1
While companies may emphasize one strategy more than another, both proacting and reacting are important to most companies. Additionally, many companies get into a reacting mode by accident. Competitors launch new products or new features earlier than anticipated and then companies are in a new mode: catch-up. When reacting degenerates into catch-up is when companies face trouble. Getting out of catch-up mode can be very difficult because it usually puts pressure on speed of development, which leads to a deemphasis on quality, which results in slower speed, leading to another round of more catch-up and further downward spiral.
Proacting and Reacting, anticipating, and adaptation -- these are strategies that agile leaders need to consider. They need to develop guidelines so development teams understand these strategies and how they relate to business objectives.
Getting an organization to shed deeply rooted notions of conventional, heroic leadership is difficult and like weeding a garden: it requires vigilance and hard work. While the collaborative leadership program painted here appears to go against ingrained behavior patterns that are wired deep within our minds if not our DNA, we must persist despite the daunting effort. I am not so sure we can afford this biological or psychological -- and silo-creating -- baggage any longer.
The future of effective human-computer systems is at stake. IT leaders and business leaders need to understand that collaboration and involvement of others in the conceptualization, design, and implementation of change (and IT systems are change too) isn't just something to be checked off a list. Collaboration across groups needs to be embedded deeply into how the organization designs and implements change.
"Heroic Leadership Creates Perpetual Silos,"
Business-IT Strategies E-Mail Advisor, 6 January 2010
Good software architecture is a concept that has been and continues to be overdue. Like good design, GSA is difficult to achieve. How many of us have been frustrated by bad bottle openers and quirky corkscrews, let alone challenges associated with software interoperability? We know good design when we interact with it, but most efforts fall far short of the satisfaction you get when you pick up an Oxo Good Grips vegetable peeler, use a Swiss Army knife, pour water from an Alessi kettle, or place a Post-it Note on a colleague's desk.
A mentor of mine put it well when he sagely observed that simply because someone is given carpenter tools doesn't make them a master carpenter.
"SOA Tipping Point,"
Business Technology Trends & Impacts Council Opinion, Vol. 10, No. 10
The delivery of social media technologies (SMT) also challenges technology acquisition, deployment, and support models. Social media -- while far from free -- can be relatively inexpensive, certainly when compared with the enterprise licensing models of the past. It's also easier to deploy by increasingly technologically savvy business professionals who no longer need data center high priests to make technology work. Anyone can go to the Web and deploy SMT. This represents a threat and an opportunity. It threatens the control of IT but helps businesses think creatively about innovation, customer service, product lifecycle management, and countless other business processes. The acquisition, deployment, and support of SMT will necessarily be shared among internal and external technology providers -- and by business and technology professionals. Everyone will need to widen and deepen their social media competencies.
[The client-vendor relationship in the IT outsourcing context] is qualitatively different from the typical client-vendor relationship that characterizes the bulk of economic exchanges. In fact, the client-vendor relationship in the IT outsourcing context is a prototypical example of value cocreation arrangements, where two or more organizations actively cooperate over an extended period of time in the development and realization of economic value. The need for a value cocreation paradigm for IT outsourcing seems inevitable as IT is typically so deeply embedded in firm operations that an arm's-length relationship with the IT services provider only proves unable to adapt to the changing needs of the customer organization over time. Yet, despite the intuitive theoretical appeal of the value cocreation paradigm in this context, ... we are today very far from this ideal state.
History tells us that the Romans were not great conceptual thinkers, certainly not on a par with the Greeks. The Romans were great at a few key things: war, administration, and engineering, and all of these things hung together. War made it possible for a small city state in Italy ultimately to conquer a very large portion of the known world; administration made it possible to govern and administer Rome's huge, far-flung, and diverse empire; and engineering made it possible to build the roads, aqueducts, walls, and castles to secure and provision that empire.
Why is any of this important to today's C-level executives and what role does enterprise architecture play in any of this? Well, the first thing is that over time, the Romans learned to think long-term. When they captured a new province, the first thing they did was to begin to build roads and fortifications, castles, and aqueducts to allow them to protect and supply what they had conquered.
Modern enterprises would do well to emulate the Romans' thinking. Take a major merger. In addition to working to integrate the financial and marketing aspects of this new business empire, top management should set the IT planners and engineers at work to integrate the data and systems from these different merged units. IT is today's most critical infrastructure.
"Why Is the Roman Coliseum Still Standing?,"
Enterprise Architecture E-Mail Advisor, 6 January 2010
One interesting element of drift is that those "drifting away" from the standard procedures believe that it isn't really that much of a problem because they believe that someone else will be following the procedures. In other words, someone else will be conservatively managing the risk, even if you aren't.
Drift might be a good explanation for the financial meltdown, as everyone pushing the limits thought everyone else -- especially regulators and internal risk managers -- would be doing their job ensuring too much risk wasn't being taken on.
There's often an unfortunate tendency for IT governance to focus on prioritization of existing resources and the demands for those resources. Years ago a CIO remarked to us, "If prioritization merely reorders the same old projects, who cares? What we need is better projects!" In IT governance terms, he's asking for engagement with the business to provide better insight into what is possible and, more important, what is potentially transforming for the business. Without question, this is an important, maybe even dominant, aspect of IT governance.
"Leveraging IT Governance When the Chips Are Down,"
Cutter IT Journal, Vol. 22, No. 12
We are literally surrounded by examples of how disrupted flow affects our daily lives. However, software delivery in general seems to ignore how disruptions in flow cost time and therefore money. When I speak to teams about using the concept of core hours -- a period of time during the workday when the team works on nothing but the main project -- I ask about how they feel when they're able to work uninterrupted for a reasonable number of hours. I consistently hear terms like "in the zone" and "on fire," and there is palpable delight when people speak of those times. That's what flow feels like. If it feels that good, why not seek to achieve it as often and for as long as possible?
"Confessions of a Flow Junkie,"
Agile Product & Project Management Executive Update, Vol. 10, No. 22
IT organizations have to be specially vigilant to recognize where geography makes things difficult. IT may have to adopt special mechanisms for overcoming the separateness; perhaps this means colocating or exchanging of staff. Perhaps this means emphasizing the customer-contact roles beyond what is necessary simply to carry on the communications and planning. Perhaps this means accepting some aspects of decentralization. But something has to be done, because unchecked, the silos of business and IT will be even stronger. And that's unfortunate.
I expect adoption of on-demand/cloud-based BI and data warehousing to experience steady growth in 2010. Several trends will be responsible for this. First, the state of the economy is having a strong effect on corporate BI and data warehouse funding, and many IT organizations are considerably underresourced while at the same time under a lot of pressure to cut costs. Consequently, looking to do more with less, they realize that BI is a very important but costly necessity, so they are turning to on-demand/cloud offerings and services. Second, providers are continually introducing more comprehensive on-demand/cloud-based offerings. And third, the concept is not so new anymore. Consequently, it appears that end-user organizations are becoming more open to utilizing outside applications and services to meet at least some of their BI and data management needs.
I expect adoption of on-demand/cloud-based BI and data warehousing to experience steady growth in 2010. Several trends will be responsible for this. First, the state of the economy is having a strong effect on corporate BI and data warehouse funding, and many IT organizations are considerably underresourced while at the same time under a lot of pressure to cut costs. Consequently, looking to do more with less, they realize that BI is a very important but costly necessity, so they are turning to on-demand/cloud offerings and services. Second, providers are continually introducing more comprehensive on-demand/cloud-based offerings. And third, the concept is not so new anymore. Consequently, it appears that end-user organizations are becoming more open to utilizing outside applications and services to meet at least some of their BI and data management needs.
The "trends" component ... is not the fact that the airborne Internet is coming, but that it's actually here. Soon we'll be seeing "full-service" airlines charging for the service and discount airlines giving it away. And, now the already beleaguered airlines are going to have to adapt. Some will move quickly and others will lag behind. My current favorite airline, Southwest, has been leading the charge in putting plugs and work areas in their waiting areas -- a welcome feature. But they don't yet have universal wireless available. But that may be unnecessary in the future. With netbooks and 4G networks, everyone may be online all the time anyway, at least on the ground. With the airborne Internet, the real trick will be how to leverage this connectivity and not make us or our employees any more jumpy than we/they already are. We have to give people what they want when they want it, Internet-wise, but we also have to do so with a light touch.
"The Really Mobile Internet,"
Business Technology Trends & Impacts E-Mail Advisor, 10 December 2009
Organizations need to become much more aware of what they're spending on IT, how they're spending it, and the impact their investments are generating. Traditional IT finance organizations are quite limited in their budgeting capabilities. In fact, they're essentially accountants that develop and manage annual budgets. The new skills and capabilities call for active, strategic accounting and finance. They call for optimization and creative financing. They call for exquisite metrics-based accounting and performance monitoring and management that provides real-time data about the capabilities and availabilities of the IT organization.
Implementing green IT across the organization should be seen as a comprehensive business transformation effort that affects the entire organization and not just one or two of its parts. For example, the business leadership of the organization should prepare for changes to the business model as well as the product portfolio of a business as the business undertakes a greening effort. This change is akin to the change that occurs with any other technology-based business transformation. Therefore, another key message that emerges ... is that metrics and measurements play a significant role in the green transformation (which is a business transformation) of the organization.
Finally, green transformation also implies IT systems upgrades, use of emerging technologies, implementation and integration of CEMS, and changes to the organizational structure. This results in a related but large area of investigation that can be called environmental intelligence. Needless to say, further investigation and validation of green IT metrics is required.
Organizations need to become much more aware of what they're spending on IT, how they're spending it, and the impact their investments are generating. Traditional IT finance organizations are quite limited in their budgeting capabilities. In fact, they're essentially accountants that develop and manage annual budgets. The new skills and capabilities call for active, strategic accounting and finance. They call for optimization and creative financing. They call for exquisite metrics-based accounting and performance monitoring and management that provides real-time data about the capabilities and availabilities of the IT organization.
But there are problems with the current keepers of technology. Some of them insist that operational technology is still underappreciated, that discipline is required now more than ever, that standardization is still an essential best practice, and that reporting relationships need to centralize -- and then recentralize. They wave the compliance and regulatory banners every chance they get. They're suspicious of the new "shared" technologies, such as Web 2.0 and especially social media, and they don't trust their business partners to do the right things when it comes to technology acquisition, deployment, or support. They just don't. In fact, much of the "fix my computer" crowd believes that the so-called business technologists who sit in businesses and wax poetically about technology really understand only what technology might do and virtually nothing about how technology works or what's involved in delivering cost-effective technology to enable business processes.
The other side of the aisle is where strategic business technologists live and breathe. They discount all technology that doesn't touch a customer in one way or another. They are bored with the old arguments about standards, alignment, chargebacks, and project management. They want operational technology to just work (and scale securely, of course), and they want the people who make it work to work cheaply -- and efficiently -- regardless of where they're physically located.
"Partnering" -- besides being a mandatory buzzword -- is a curious term. Nowadays, instead of taking over a company, we partner with them. We don't sell anything anymore; we partner. And now, rather than outsourcing, we create strategic partnerships. While the goal of an amicable and mutually rewarding relationship is admirable, what each party truly expects from the other in an outsourcing arrangement formed under a "partnering vision" is quite different.
The client often wants a "well-behaving provider." But what the client means by "well-behaving" is a provider that accepts nearly infinite scope creep without a commensurate increase in price, immediately reacts to the client's ad hoc needs (at no charge), and performs what the client really meant in the specification instead of what was actually written and quoted (again, at no charge) -- all the while acting under a fixed-price, punitive contract. This interpretation illustrates the client's version of partnering as an environment where "the client is always right." A "master/slave" relationship appears to be the goal.
Data integration and data integrity requirements can pose significant problems for organizations implementing business performance management initiatives due to the sheer number of sources required to be integrated and the nature and composition of those source systems. As a rule of thumb, I recommend organizations to plan on integrating approximately 10-15 sources to adequately support performance management initiatives.
Planning, budgeting, and forecasting systems, followed by spreadsheets, legacy systems, ERP applications, and CRM systems rank highest among data sources organizations are required to integrate to support their business performance management efforts.
The fear of change and thus the need for change management may have little to do with the magnitude of change itself and everything to do with the magnitude of the desire for excellence within the people themselves. How do leaders cultivate a desire for excellence within teams? Leaders need to inspire, motivate, and ignite the transformation within those on the fence between indifference and desire. What are the 20 steps for creating a passion for excellence? The economy is helping out with one of those 20 steps: establishing a deep fear of irrelevancy.
It really doesn't matter where you are or what device you're using. You can still track sales, change prices, and replenish inventories whenever you like -- with the right technology infrastructure, applications, and delivery mechanisms. The era of fixed-location computing is over. Constant communication is common. The implications for total mobility are far-reaching. On the one hand, there are obvious implications about technology support: technology must always be on, reliable, scalable, and secure. On the other hand, mobile computing assumes management and governance protocols that by definition must be flexible and adaptive. Mobility is all about agility.
One way to jump into mobility services is to define what the virtual office would look like for your industry and for your company. You can then back mobility services into the virtual office model.
Typically, the company that built them, with bugs fixed "free" for some warranty period, often two to four months, maintains outsourced projects. Even in good projects, only 90% of bugs are discovered and fixed before release. But due to the accelerated ramp down, a much smaller percentage of bugs are being found on offshore projects. And, with at best 800 bugs undiscovered (probably more like 2,000), the costs are going to show up during the maintenance phase. When you consider that outsourcing only saves about $250K on a $3.5M project, and the maintenance costs are likely to be at least three times as much (based on 3x bug count), it will cost you more, to get a poorer quality product ... just the facts!
It is critical to acknowledge that the use of outsourcing should never imply less effort in managing IT, only a different emphasis. For example, the top IT manager will need to concentrate more on direction, strategy, and implementation than with routine service delivery and staff management. The internal audit function, which may have limited reviews to comply with company policies in the past, must have a more active role. Auditing (compliance, validation, and value for money) is generally more extensive and frequent because the organization's accountability hasn't changed, but direct control and physical proximity are now absent, and the introduction of profit as a key motivator behind everything the provider does (e.g., its advice/recommendations, service delivery, and resourcing strategies) must be taken into account. Planning becomes absolutely critical in outsourced environments. It is the familiar "garbage in, garbage out" paradigm; the only difference is that "outsourcing garbage" costs you much more. There is an increased need to appropriately authorize plans, costs, recommendations, and actions, and then sign off on deliverables -- if only for the reason that most providers will not begin work without appropriate approvals to make sure they get paid. New requirements, and those that require changes from what was originally agreed to, will need to be negotiated and will have a cost impact.
Cutter Consortium helps companies leverage IT for competitive advantage and business success through its comprehensive range of consulting, training and content, provided by the leading expert practitioners in business and IT.
Learn more »
