Following up on my last post on Bimodal IT, I came across this excellent article from Jason Bloomberg with Intellyx, in alignment with my last post about the real nature of the relationship between Agile and Traditional IT. Jason states:
Bimodal IT is simply an excuse to keep doing IT poorly.
Agreed. Traditional IT at worst is slow, siloed, stonewalling, increasingly irrelevant and at risk.
Lydia Leong with Gartner has posted this article identifying a compelling term in enterprise software development: bimodal IT, the emergence of new development in parallel with traditional internal practice. I agree wholeheartedly. However, I don’t agree with Lydia on this point:
Bimodal IT also implies that hybrid IT is really simply the peaceful coexistence of non-cloud and cloud application components…
The relationship is definitely not peaceful. Agile IT concepts represent much needed change for traditional IT and will transform it. Traditional IT is subject to the same set of compelling drivers as the newer approach: open source, cloud, maturity of powerful development tools, and many others. So in fact, bimodal IT actually represents a new awareness of the power of enterprise development to directly support strategic business value through software.
I started reading “Enterprise Architecture as Strategy” recently because it’s a tempting title and, although it was published a while ago, I thought it would provide good academic reference for our work promoting the use of information systems to solve key problems within businesses. The introduction definitely provides this sense:
We believe [companies] execute better because they have a better foundation for execution. They have embedded technology in their processes so that they can efficiently and reliably execute tough decisions about what operations they must execute well, and they’ve implemented the IT systems they need to digitize those operations. These actions have made IT an asset rather than a liability and have created a foundation for business agility.
Great, yes, good start. Unfortunately the book doesn’t deliver too much more than that, that’s relevant to today’s context anyway. On that point, probably the most interesting aspect of the book is the difference it shows in IT approach in 2006 versus today. Concepts of how to create large systems from very diverse components and allow those components to change rapidly and independently (i.e., SOA, Messaging, Reactive, etc.) were just emerging, and these terms aren’t mentioned in the book. It seems that enterprise technology in 2006 really believed that it would eventually embrace and surround all users with its formal process, and that these aspects would be neatly governed by the CIO and the very efficient IT department.
Ugh, the reality of it all. The narrative reaches a peak on this vision when, in chapter 8, when, after prior chapters describing 4 stages of architectural maturity, we get a glimpse the future according to 2006:
We call the fifth stage of architecture maturity “Dynamic Venturing.” Building naturally on the capabilities developed in the Business Modularity stage, the fifth stage extends the concept of reusable modules to enable companies to rapidly reconfigure their portfolios of businesses. Based on the core capabilitieis of the company, managers will look for opportunities to partner, acquire, joint-venture, collaborate, integrate, and connect with many other companies.
Chapter 8 goes on to describe the “Dynamic Venturing” stage as characterized by
Seamless merging with partners’ systems.
Sorry… wrong. The reality today is that we have a much more highly fragmented, powerful, independent, and quickly evolving ecosystem than the authors were able to imagine. The fundamental nature of information technology and its strategic use in support of strategic value is very different than the high formalism envisioned in 2006. In fact it’s so different, that the really compelling use of IT is frequently outside the domain of the CIO and the structured IT department entirely. See this article as an example.
Here’s a good article that appeared recently in Business Insider (originally posted by Lennie Pruss at RRE Ventures) discussing key concepts about the evolving role and importance of developers, as well as the increasingly strategic value of software created within the enterprise:
As technology has shifted from enabler of business process, to enabler of product or service, to the very product or service itself, we’ve seen IT transform from a cost center that is adjunct to core business to a profit center that is its lifeblood.
The curve above shows the progression of enterprise systems, from off-the-shelf vendor components on the left, to highly customized solutions on the right.
The y-axis is scope. Off-the-shelf products such as Oracle and SAP ERP are large scope since they provide extensive, general functionality that can cover many basic needs in common with all enterprises or a complete industry vertical.
As a business begins to recognize strategic value in operations information technology, it will grow the technical solutions portfolio to include more specific components that are smaller in scope and have increasingly precise purpose for the business, such as CRM. These are positioned to the right in the diagram. They are more custom to the specific operating needs of each individual enterprise.
At some point, the enterprise will identify a strategic opportunity for a digital solution that is not available from any vendor. Frequently this is in the form of a need for integration between existing components. The enterprise can choose to develop the solution internally, or work with a vendor to create this customized solution.
In either case, this customization will ideally be small in scope, on the far right side of the diagram. By leveraging general off-the-shelf components and limiting customization to only strategic needs such as integration, and where third party solutions do not exist, technology organizations can optimize resources and most efficiently become real partners to the businesses they serve.
IKEA is a powerful example of the strategic role of enterprise information systems. IKEA value principle of design and quality at competitive price, delivered through a unique, efficient, friendly customer experience is supported at every point by enterprise systems that reflect, encapsulate and drive these values. The ecosystem of components comprising the EIS is highly diverse, but have been integrated by IKEA to create an overall system that uniquely fits the business. Because IKEA is highly vertically integrated, interoperation with a large range of vendor systems is key to competitive advantage.
A powerful example of customization in support of fundamental value principles is IKEA iSell, a customer facing inventory system that provides an experience that is uniquely IKEA. One customer review states:
I love iSell, if you couldn’t tell. It’s efficient, it’s time-saving, it’s complete, and it’s flexible enough to fit your needs…and most of all, it’s personal. It helps bridge customers who visit different stores…it makes IKEA more unified, and makes your life easier, better.
A presentation on one of the unique aspects of iSell- the ability to switch between centralized and decentralized modes for offline ordering, is here.
Another example of customization driving value is IKEA kitchen planning software, linked here. This application is smart (fat) client that runs on end user desktops, enabling customers to design product layouts. The application output is a file containing the customer order, which can then be transferred into iSell for fulfillment. The experience of interacting with the system at this touchpoint is uniquely IKEA- efficient, friendly, and cost effective.
Software engineers are a fundamental resource for businesses that produce software. They are a key source and driver of value for organizations.
But, for companies that create software that’s mainly for internal use, i.e. operations and customer lifecycle management systems, this fact represents one of the most significant hurdles that prevent companies from realizing the really astonishing benefits that internal development programs can achieve.
Part of the reason is that internal software production requires internal pricing. When one business unit wants to purchase the product or service of another business unit in the same organization, what should the price be? Commonly for internal software, the answer is simple cost based pricing. Consequently the supplier– software engineers– are able to capture very little of the value they are helping to create.
Another possibly more significant reason is organization structure. Particularly in large companies, software engineers and others that are responsible for actually executing work, are more likely to become surrounded by layers of management and other overhead that are adept at representing value while contributing very little to its creation. It’s a natural process: those that execute are very busy, but those that do not execute are free to pursue these personally profitable and ultimately very damaging activities. It’s an enormously demotivating factor for engineering teams and it reduces or even eliminates the huge potential of internal software production programs.
This is a tremendous loss to the organization. The development of internal software is an extremely powerful source of value and a huge change agent. It’s critically important that the organization recognize software engineers and protect this key resource by correctly attributing value creation to its source. This is the key factor driving the upward spiral as internal software production becomes capable of its full potential.
It’s a strange dynamic that allows this paradox to exist. In fact it’s one of the core propositions of books like Execution: The Discipline of Getting Things Done and Drive that elimination of this cultural pattern is a primary objective for businesses to succeed. The reality is that problems like these are deeply ingrained and stubbornly difficult to change. But not impossible.
Independent of the politics of the new Affordable Care Act, the development of software systems implementing the law sets a new precedent in important case studies for IT. Here’s a fascinating quote from the New York Times on the importance of these systems to the success of the new policy:
As a small coterie of grim-faced advisers shuffled into the Oval Office on the evening of Oct. 15, President Obama’s chief domestic accomplishment was falling apart 24 miles away, at a bustling high-tech data center in suburban Virginia…For 90 excruciating minutes, a furious and frustrated president peppered his team with questions, drilling into the arcane minutiae of web design as he struggled to understand the scope of a crisis that suddenly threatened his presidency…Out of that tense Oval Office meeting grew a frantic effort aimed at rescuing not only the insurance portal and Mr. Obama’s credibility, but also the Democratic philosophy that an activist government can solve big, complex social problems.” Sheryl Gay Stolberg and Michael D. Shear in The New York Times.
This is a compelling example of the strategic importance of IT. These systems are a major component of the new policy, and the success of the policy is absolutely linked to the success of the technology.
As an enterprise software development program matures, it produces more and more effective output. At some point, as the value of this output continues to increase, the program begins to bridge across the classical accounting definitions of cost and profit center. This can be an extremely powerful change agent for the enterprise.
Of course, the large majority of enterprises consider software development to be simply a task necessary to their business. By definition, revenue cannot be attributed to it; it is purely a cost center. These organizations are focused only on the direct benefits of development.
But hidden in this stereotype is an enormous opportunity for companies that get it right. Developing software within the enterprise has both direct and indirect benefits. To see these as simply cost oriented, is to be blind to the most important aspects of these programs.
In general, successful development of software within an enterprise produces two categories of benefit to the organization: direct, and indirect. The direct benefits are exceptionally powerful. But it’s the indirect benefits that have the potential to create the kind of truly compelling business impact we’re talking about.
Direct benefits of developing software within the enterprise
The main driver for development of software within an organization, is reduction of cost. Common targets include automation of repetitive human activities, reduction of errors, streamlining of processes, and increased repeatability. All of these involve reduced business expense; they are cost benefits.
Indirect benefits of developing software from within the enterprise
The indirect benefits are less clear, but more important:
An organization developing software successfully within an enterprise, is in fact a bridge between the two classical accounting concepts of cost and profit, because it can be both.
Controversial? Definitely. The categorization of business units as either cost or profit center is an established and trusted accounting concept. It’s absolutely problematic for this venerable system to account for strategic IT, which has the potential to bridge these definitions and switch quickly between them.
That potential is enormous. It can drive tremendous, positive change across the enterprise.
“Let’s get all the stakeholders at the table” is a common charter when businesses decide collectively to invest in a software development effort to benefit business functions. It’s an important statement. Enterprise software is unique among all other forms of software because organizational consensus is so important. In fact, consensus challenge can be more important than technical challenge.
Unfortunately the IT team are often not included during this initial stage. Business leaders, along with business and operations stakeholders, generally will meet to define the high level objectives and design of the to-be system. IT is considered outside of this effort; their role is to accept and implement these plans, but not to participate in their creation.
This is a mistake. IT should certainly be included in discussions in which all stakeholders are meant to have representation.
First of all, there’s a real benefit in including IT contributors early in the process because it enables this important group to participate, understand, and own the overall objectives. Creating consensus is a major benefit of the successful software initiative, and achieving this benefit can start right away. Downstream in the process, detailed business analysis will result in software requirements that are long and complex, but the initial, high level plan is likely very simple. Enabling IT to understand the spirit of the effort makes an enormous difference in the interpretation of requirements, and therefore the quality of the end product.
Software development is an intensive, thorough process. It’s where the rubber meets the road: no amount of analysis prior to the start of development can prepare for the realities that will be uncovered during implementation. The job of the software team is to methodically step through business logic. This process naturally leads to detailed questions about states of the system that other stakeholders cannot possibly uncover, no matter how thorough their analysis. It’s natural that through this rigorous process, the software team will become extremely familiar with the real business cases, and all of their underlying detail. This knowledge and experience is invaluable to the steering team during high level planning and objective setting; it is a foundation to build the scaffolding of any new effort.
IT possesses unique knowledge of the technology; they also have unique knowledge of the business domain. In fact, no other group has quite the depth of experience or perspective as the IT group does about the functions of the business.
And then, there is the implementation curve itself. A rule inside development is that 80% of the effort of the implementation will occur during the last 20% of the project. In my experience, half again of that effort will occur during the last 5%. It’s only until the implementation reaches this level of progress that the real work is uncovered. There’s simply no way to simulate, analyze, or re-create this curve prior to beginning the implementation; it’s a reality that is difficult to predict and must be experienced. The software team that endures this kind of rigor, day in and day out, will gain an intensive understanding of the enterprise business domain. This knowledge is exceptionally valuable to the business. It’s a finely distilled result of the effort of the implementation, and it is of direct benefit to future efforts that create value through IT.
The IT team is composed of very smart people. Software itself can be complicated. Enterprise software can be more, or less, complicated to implement than other forms of software, but it is certainly complex in it’s own right. Enterprise software is the merger of the technical domain, in which many useful and mainstream technologies exist and must be well understood to be used correctly, and the business domain- specifically, how technologies can be leveraged to solve business problems. This means that enterprise developers have a lot to master. It also means that they’re good at a lot of things, and can potentially fill many roles within the team. Certainly this combination of intelligence and mastery should be included by the steering committee making decisions for the future of an enterprise software system.
The software development team is a valuable component of the enterprise. They should be included as a key stakeholder during any decision about the future of an enterprise development program, and the business value that can be generated through software.
Recent Comments