Rettig is right that enterprise reuse is difficult task, I would strongly argue against it being impossible. Enterprise computing only works when you strike an appropriate balance between commodity computing and the innovative layer which enables business to have a competitive differentiator. One could argue that having such a commodity based framework actually enables application developers to build software functionality to further their respective business.

For some odd reason, probably to CYA, people seem to think that more is much better than less to the detriment of actually getting things accomplished. How many of us create endless reports that are never reviewed nor is any improvement made to the systems or applications reported upon. Our applications have become like expensive dishwashers; lots of buttons and options but nobody uses any of them except the basic ones that wash the dishes. Maybe that's a bad analogy since most dishwashers actually provide a valuable service. I'm not sure if most dustom designed software can say that.

"Simple and effective" solutions are what IT and business should be shooting for. What needs to be done and what is the easiest way to do it.

I have been implementing ERP systems for over 30 years and there is no doubt in my mind that their complexity negates the value of any and all benefits of their features.

It is not complexity by itself that is harmful it is the unexpected and counter intuitive outcome of simple transactions that baffles clients, IT, and consultants.

Elephants are not meant to be eaten in one bite, however, "fully integrated" means you must deal with the the total elephant - whether you want to or not.

Jim Finn

If you are buying your ERP system, you are always buying more than you need. (Not that internally-developed applications are exempt from goldbricking and requirements bloat.)

What, then, would help us implement selectively?

In the midst of an ERP implementation at an SME (~400 employees), I would argue that it is knowledge of the new system that is the chief barrier to being selective. That knowledge must be more easily transferrable -- from the vendor to the IT customer, and from IT customer to end user, and among end users.

So, what would make it easier to learn a complex COTS application like an ERP or CRM? Certainly, existing documentation is inadequate. User guides and on-line help are at such a low level, important assumptions and relationships are not visible within the module, much less across modules. Data dictionaries say nothing about triggers and stored procedures; ditto for data models (no place on an ERD for them). I haven't seen a systems manual that addresses key functional and data relationships -- these days, they're only worth reading by network and data admins. I've learned to not expect much else in the way of documentation.

It's a whole 'nother thread to talk about why this situation exists and what we can/should do about it.

While there are a number of points made in this post by Cynthia are good and really quite obvious to most, there are some that clearly indicate a lack of perspective and appreciation of newer paradigms of building systems.

Complexity is bound to happen in any evolutionary process, and IT is no different. Maturity follows complexity as the dust settles and which is why we no longer fret about memory, networks, storage, servers, Internet connectivity, etc. the way we had to in the past. This is natural evolution that happens everywhere.

I also think her appreciation of most CXO's perceptions of the IT department and software is also a little misplaced - while they definitely need to be more educated on technology so it has a closer link to the business, I doubt that most CXO's blindly trust technology to be the magic bullet. I think they are the ones most skeptical of IT delivering real value as they have had a history of things not scaling, being reliable, performing as expected etc. That is one of the roadblocks for even SOA adoption as it is less of technology and more about the business and alignment. All her references to SOA are in the context of "web-services" or web-service wrappers as additional code that layers on top of existing buggy code. Given that analogy, she should also be against object oriented or modular programming practices, as one buggy object could impact a thousand different pieces of software using it.

SOA is a new way of building systems and solutions that has matured out of the success that many large shared services deployments have had. It is more to do with business folks thinking about what they do, and having the technology folk�s work with them to build services on the same lines. This would avoid the band-aid or spaghetti systems that exist today. Add to that the standards and protocols and we have systems that potentially have better agility than before.

SOA is no silver bullet, and cannot be done overnight, but it is a better paradigm to make more robust and scalable systems. And while SOA does not reduce complexity - it makes it easier to manage - if done right. In the end - software can only be as good as the humans developing it, and no technology or paradigm can fix that problem.

For more insight on SOA visit the SOA Consortium at http://www.soa-consortium.org an SOA advocacy group consisting of end user companies, practitioners and product vendors.

http://www.sdgc.com

I agree with L. Murphy that companies tend to "overbuy" their systems. Too often the tack from management (and IT is just as guilty) is to say "Look at all the wonderful things we will get". All those wonderful things will never happen if the system does not address its essential purpose. A manufacturing system should deliver solid bills and manufacturing orders, based upon an MRP module. An accounting system should handle the receivables and payables and financials in a straight forward way. An order entry system should take orders, manually or via EDI. If the purchase of the ERP system is to handle your day to day operations in a methodical, repetitive way, that's the right track. Everything else is add-on and secondary to the purpose. In thirty years and 20 ERP's, the only implementations I consider to be successful were with smaller companies who wanted to integrate the business activities that got the order in, got the order out, and collected the cash. Once that was done, and functioning well, you can then move on to data warehousing, reporting, CRM, etc. These companies grow from 20 million to 120 million in the span of 5 or 10 years because their systems deliver. The billion dollar companies I've worked for during ERP implementations or upgrades never derived such benefit.

Comparing enterprise software applications and how they connect functionally in their user environment with object-oriented / services-oriented approach to application architecture is like comparing apples and oranges.

It's not software code we're reusing (although that works, too), its the data, business rules and transformational processing. I prefer a bricks and mortar metaphor over the more simplistic lego concept. When enterprise systems are architected (not just marketed) to support SOA, there's plenty of fertile ground to orchestrate emergent applications that foster business innovation in that connecting layer. I've seen it happen.

From what I've seen, the real complexity is not in how code is written or applications architected, but in how data quality and business rules are governed and maintained across middle-management territorial boundaries.

Perhaps the problem is that business innovation is not as exciting to computer scientists as software innovation is.

But even at that, interoperable SOA -- though it takes some discipline on the part of the application architects (and a willingness to suppress your [my favorite codebase/platform here] fundmentalist fervor) -- is very doable. And it happens every day in my world at a much higher level than reusable code snippets.

Out of Scope for this post:
1) Enterprise Software Vendors
2) Application Architecture
3) Integration Approach
4) Business Process and Technology Solutions

In Scope for this Post:
1) Too many companies choose the wrong implementation experts because there are too many to choose from, ie. quality of advise/assistance is, on average, poor
2) Too many companies don't have the political will to be excellent and stable. Rewarding or promoting "slash and burn" managers is antithetical to success in implementing enterprise systems. Once you embark, stability and incremental improvements are best, not senseless innovation.
3) Too many enterprise software selection processes are tainted, full of malfeasance, and conflict of interests, and poorly executed.
4) Pundits, including Rettig, are given too much airtime.

In terms of the thought that complexity limits flexibility, isn't the opposite true that flexibility inherently drives complexity? Based on my research and observations, flexibility is a driving factor leading to IT Effectiveness, as measured by IT's ability to meet business demand towards sustained competitive advantage, or as I have termed it the business-IT equilibrium model.

To focus on the relationship between flexibility and complexity, if we consider SOA, and the inherent modularity that it requires (whether as part of an ERP, CRM, or other solution), then the challenge for IT would appear not to be to limit complexity, but to manage it in such a way that it can be a enabler rather than an anchor to business agility and growth. The issue, it would seem, is that the tools, methods, people, and processes are not in place to effectively manage the added complexity to realize the intended business value. Middleware is a step in the right direction, as a means of integrating all of the disparate pieces, but in and of itself is another layer of complexity that is often difficult to understand, much less manage.

Therefore, my question/challenge for this topic is should we (IT) strive to limit complexity, or embrace complexity as a means of flexibility, and as such, seek ways to improve the management of increasingly complex environments such that IT Effectiveness can be optimized and business-IT equilibrium (more closely) achieved?

It is not about the enterprise software! It is about the lack of business leadership and discipline. The leadership must describe clear business goals and objectives that become requirements that IT and other business units attempt to achieve. The organizations must exercise the discipline to accomplish these goals within the time and budget available while continuing to support the business. If the software is too complex – do not choose it. Also, do not forget to look within your organization for answers to business challenges before hiring consultants and talking to software companies. Too often, the requirement presented to consultants and software vendors is “I need an ERP solution” or “I need monitoring software”. This starts a complex discussion led by consultants and vendors eager to consume business dollars.

Why deliver a one-pound box five blocks with an eighteen-wheeler when a two-wheeled bicycle messenger will do?