Follow by Email

Sunday, September 27, 2009

Modernization and Your Enterprise

I have been a systems manager and executive responsible for building enterprise systems for over 38 years.  I worked through the 1970’s when we made a transition for batch to on-line systems.  I was intimately involved in the enterprise systems software engineering activities of the 1980’s with Finkelstein, Martin, Bachman and others.  I have designed and built not one but three fully integrated enterprise systems for three separate insurance companies. 

I am extremely concerned over the state of the computer software industry today. On one hand I love the incredible tools we have.  I use a piece of software on my Blackberry that tracks every detail of my travel itinerary giving me updates on my flights including schedule changes or even gate changes.  I am using Twitter, blogs, MySpace, YouTube, along with several Google applications daily. Many of these systems like the travel system are service based reaching out and accessing dozens if not hundreds of computers and consolidating data from presentation on my Blackberry.

I look at my clients and former customers as well as my previous employers and the huge inventory of legacy code that they developed in-house or purchased from various third party vendors, many of which are no longer in business or have been acquired by some holding company that is milking the annual support and subscription but no longer enhancing the products.

I look at the “new” software and architectures that are emerging from major software vendors including former leaders in the field like IBM Corporation, HP, Sun Microsystems, Oracle, etc. and am very dismayed at what I see.

Where companies like IBM once had System Engineers that had offices at their customers place of business and worked full time at the customer site for large customers or split their time between smaller customers spending one to two days at smaller customer sites and serving as an liaison between the customer and IBM often driving new business based requirements to the development labs.  This all changed in IBM with Lou Gerstner in the early 1990’s!

IBM and many other companies like IBM were transformed from a customer centric sales and marketing company to a manufacturing company where engineers in the research labs would invent products that would be produced and attempted to be sold based on what these “brilliant computer scientists” thought the world needed. 

Often companies like IBM, Oracle, Computer Associates, and many others are driven by their marketing executives who are looking at competitors and the open source community and see products emerging that they do not have or sell that seem to be impacting the market.  The large companies respond by buying companies that have the technology their competitors are offering.  Sadly, more software is purchased today than is built by most companies.

The fundamental driver is quarterly corporate results and the stock price.  Today the CEO’s of the major hardware and software companies are driven by a need to sustain growth and increased profitability.  Companies can no longer just “do the right thing” for their customers, they must increase revenue, market share, and that all important earnings per share.

What happened to Software Engineering?


During the 1980’s Clive Finklestein came out with papers on Information Engineering (IE).  This was picked up and marketed by James Martin.  In addition Dr. E.F. Codd had introduced his papers on relational data modeling which was core to Information Engineering and Bachman, Constantine, Gane, Sarson, Yourdon, and others all got on the bandwagon.

We saw the emergence of “C.A.S.E” (Computer Aided Systems Engineering) tools that would in theory allow you to model your business and ultimately generate program code based on rigorous analysis and modeling. 

Today this is all gone.  Today we have UML and its suite of diagramming tools, which IMHO are nothing but an integrated suite of drawing, tools for programmers.  There have been books and attempts to claim that UML is a tool for architects to design systems, but if you look closely there is no discipline in the tooling to enforce any design integrity.  A developer may draw anything and represent anything any way they choose.  There is no tooling to determine the accuracy of the model that is being represented because what you are really diagramming is detailed program logic and not the business enterprise. Don’t get me wrong, the UML language is awesome with its ability to capture and represent both graphics as well as an immense amount of information about a system, but the diagrams and methodologies that implement UML like Ivor Jacobson’s USELESS case models are just well, useless. The USE CASE diagram is nothing more than a graphical version of a program specification.  It does not help a company arrive at or analyze requirements, it just communicates requirements to a programmer.

Today we have what were are calling “architects” who are in reality some bright computer science guys who don’t want to be called programmers and prefer to draw UML models than write code.  These folks are technical and focus on the technical design of your computer systems.  It is rare that they understand the business and the requirements of the business.

Where we spent two decades trying to define relational database architecture and design’s that represented your enterprise, the modern computer scientists ignore data and have taken databases back to being treated like file systems with CRUD (create, read, update delete) which was proven to be a horrible construct in the 1980’s but is something a programmer can deal with while knowing absolutely nothing about the application they are building. 

The GEEKS are driving the boat
AND
There is an iceberg ahead!


Yep, the GEEKS see the iceberg but they are analyzing what to do about it.  They are measuring it, calculating how long before we hit it, and doing all sorts of theoretical analysis. 

What should be happening and can it happen?

My vision of the future is a world where companies can build, buy, and integrate software from many sources into a custom system that fits their needs.  There should no longer be a build versus buy decision required.  You buy if you find something that works for you and performs a specific task.

I think we must break our dependency on third party ERP systems that filled a gap in systems development expertise in the 1980’s and 1990’s but are now selling old proprietary systems that lock their customers in to the “system” and limit the customers flexibility and growth.

I think that business users and not IT people should be driving systems development.  I think that IT should be a service organization that provides services on competitive basis to the business units. 

I see a world where a department manager can look at a real time diagram of the workflows in his or her department with analysis of bottlenecks and flow of work through the department and can make real time changes to the workflow or the programs used by people at various positions within the workflow. 

I see metrics on human productivity being made available to the manager with comparisons to mathematically computed standards workers that identify problems with people and problems with the system or the need for additional or yes a reduction in resources.

I see a new breed of software vendor emerge that takes us back to the early days of computer software where an individual with a great idea and a computer programmer can create a product and sell it to customers who need it.

We need to change the industry to make this happen.

The open source model is a good one for technology today.  It has not been good for business systems.  To understand Open Source you must look at its membership and management of the “not for profit” organizations that manage an open source initiative.

If you look at the membership of Eclipse.org, the Apache Foundation, the W3C, OMG, and many others, you will find people working for the major hardware and software giants of the industry.  You will find that these corporations provide funding via a membership fee paid to the organization that enables the organization to hire a small management team.  More importantly, these companies provide people whose entire job function is to work on Open Source projects, standards, and specifications.

In many cases the objective of the member is to slow or stop development that seems to be going in a direction that is counter to their best financial interests.  In many of these organizations their dialog and arguments for a new project are public in forums where you can see what people are saying and doing.

From its inception with Apache.org took over the maintenance of the NCSA HTTP server when funding for the project was dropped.   It was a technology initiative and the Apache foundations subsequent work has been technical. So has the work of many others.

We need new business oriented foundations!

The key to the plug and play type system that is controlled by its business users is a framework that can represent the “infrastructure” of a modern business enterprise.  My research clearly indicates that there are distinct commonalities between all enterprises (BTW, I include governmental organizations in the term enterprise). 





Figure 1: Enterprise Framework


Figure 1 illustrates a small example of what enterprise architecture might look like.  It is the normalization of core components of an enterprise to handle the structure of an organization and the flow of work through its processes.  The framework is dynamic and allows users to define their organization to it.

I can and probably will write a book on the subtleties of this framework but its fundamental purpose is to represent your enterprise in a stable manner that can be easily changed to reflect your organization as it grows and adapts to its environment.  The framework can easily handle mergers and acquisitions as well as new ventures or divestment of legacy operations.

You will notice that the diagram does not have traditional business objects like orders, inventory, insurance applications, policies, claims, etc. represented.  Our goal for this frame work is use an object oriented approach to implementing business objects and route documents and objects through processes and workflows that transform them to accomplish work. 

Not only can the framework manage the flow of work and documents through your enterprise and all of the transformations required to process orders, produce products, deliver them and collect money for the products but it simplifies application development and can provide the basis for independent vendors to write program code that will plug in to your systems and be immediately usable.

The framework does exist as a relational database and must have programs to manage the infrastructure itself, but it is not technology or hardware dependent and can run anywhere and should be implemented in such a fashion as to be distributed across multiple machines and environments.

The framework provides security.  There are many levels of security and responsibility built into the framework that separate the definition of jobs and what a job can do, the assignment of people to jobs and the set up of people within the system to different organizations.  There is a provision for extensive audit trails and tracking of historical data.

The framework can handle complex matrix management structures where people have many organizations in which they participate.  IBM gave customers a free directory tool to its WebSphere customers that emulated its internal “Blue Pages” directory system.  This system provided a search facility to locate people in the organization and could draw an organization chart showing who that person reported to and that persons boss all the way to the president of the company.  While this seemed like a great idea, its designers locked the organization chart into the legal structure of the company so a worker in Germany reported up to the president of IBM Germany through a German chain of command.  It did not reflect that German employee was in reality part of an international organization and his real manager was in Raleigh, North Carolina and not in Germany. 

The framework I am talking about must be flexible and handle the many permanent and temporary organizations that exist in an enterprise. 

The framework must be easy to maintain with the ability to make what would in many existing systems be catastrophic changes like inserting or removing levels of organizational units.
If we have a framework to facilitate development of modular business system components, the next step would be to form software publishing companies to handle the packaging, marketing, and sale of the work of small entrepreneurial developers that might be found in numerous colleges, universities, or businesses today.

The key to this framework is the idea that an enterprise can implement it and define itself to the framework and then drop in components written to use the components of the framework that define workflow and the organization itself to facilitate reporting, accounting, audit trails, and analysis. 

The framework may easily be extended to specific industries with template components to handle the core business objects implemented within a bank, insurance company, manufacturing company, retailer, etc.  This further simplifies the work to be done by third party developers who may focus on specific areas of expertise.

How can this work?

The framework must be built by a coalition of companies like yours! That mirrors the work done by the computer software vendors to day in the open source community. 

The framework would be available to its members and any other company at no charge.  There would be limitations on non-member participation and most likely only members would participate on the design committees and review boards. 

The bottom line is it is time to take back computing from the geeks and put the business back into business systems.

I will be describing the Enterprise Framework more in comping posts. Stay tuned.

Bob Cancilla, Principal
RJ Cancilla & Associates

Office:     916-226-4951
Mobile:    562-290-2849
Fax:                916-690-8453
eMail:        rcancill@mac.com
Skype:    bob_cancilla



Saturday, September 19, 2009

Enterprise Modernization – The Modern Corporate System

What a mouthful of words.  Perhaps the biggest buzzword (or phrase) in the market today is “Enterprise Modernization”. 

Many vendors are selling you software to convert existing systems written in old “legacy” languages like COBOL or RPG (on the iSeries) to a “modern” platform neutral language. 

You are being told you need to adopt Web 2.0 and SOA (Service Oriented Architecture).  Get rid of those 3270 and 5250 screens and replace them with modern web based UI’s. You need this product or that product, and you most certainly need an army of consultants to help you get there (do they actually tell you where there is?). 

Throw some new buzzwords into the mix like Cloud Computing or SaaS (Software as a Service) and it becomes even more challenging to digest.

This blog is about corporate enterprise level systems.  I may establish myself as a dinosaur and the last of a breed of folks who had the audacity to believe that we could (and did) create integrated enterprise systems (now called ERP by certain vendors).  Today you and your C-Level executives are being told that your IT organization cannot build large scale ERP systems or that it is a redundant and unnecessary activity and you should just buy one.

In this blog over the coming days and weeks, I want to examine the current state of modern business computing and try and separate hype and reality. I also want to focus on key development initiatives including building a solid “business infrastructure” that can help guide any modern business (large or small) through the future of constantly changing computer technology.

The Software Industry Today


There are two fundamental directions being taken by major software companies today. 
  • Some like IBM, Sun, HP, and others have made a deliberate decision to stay out of the business of application systems and leave business systems to their partners.  These companies focus on tools and middleware that they hope other business partners and customers will use in the development of their business systems.

  • The ERP vendors who have now been dominating the market place with their end-to-end turn key systems for many years try and keep corporations captive within their systems maintaining extremely large annual maintenance or subscription revenue streams.  They want you to stay within the confines of the system they provide.  If ever there was a need for modernization it is with most of the software sold by these vendors.  Today many major ERP systems are over 20 years old, often without rewrites to stay current with modern technology. 

Many software vendors today will tell C-Level management at your company that internal IT is no longer capable of addressing the needs of the modern corporation or responding in a timely manner with high quality business systems.

The Reality of Corporate Systems Today

The reality of today’s systems depends a great deal on where your corporation is headquartered.  Europeans and South Americans tend to focus on the needs of the corporation or business as an entity.  U.S. based companies tend to delegate computer systems to their business units and treat computer systems as a tool for a business unit executive to use and control.  In Europe and South America, executives remain in place for long periods of time.  In the U.S. people are very mobile and change jobs frequently often creating a lack of continuity in corporate leadership.

In the typical large U.S. Corporation you have mix of virtually every hardware platform known to man and software from many vendors.  Frequently there is no such thing as “enterprise systems” and the corporate accounting office demanding input from local systems to build a corporate ledger provides their only corporate level integration.

A few years ago IBM gave away an employee directory product for use on its web servers that was based on its internal “Blue Pages” software.  You could search for and look up any employee in your enterprise.  You could see an organization chart showing whom that person reported to and see the chain of command from the person all the way up to the president of the company.  You could also see whom a manager managed.  It was a great tool as far as it went. 

The limitation was that tools designers decided that the legal boundaries of a country should be reflected within the system.  You could see whom a person worked for within their country. Unfortunately, this was often not the true organization structure of the enterprise.  While a person had a physical reporting relationship to a manager in their country, they might take operational direction from a manager in another country. The reality was that the true organization spanned countries but the system did not. The bottom line is a great idea for a software product failed to deliver what was really needed.

This point illustrates that there are many views of a company’s organization that are valid and necessary.  All too frequently technologists do not see or address these views.

Build versus Buy

At one time I would have vehemently argued in favor of in-house development in order to provide your company with the best possible systems giving your company a competitive advantage over others.  Today I see a combination of build and buy as the best solution.

Today I would advocate buy, build, and integrate. 

In subsequent postings, I will explore how you can manage buying best of breed 3rd party software from multiple vendors, building internal applications, and integrating systems across diverse hardware platforms into a corporate system that meets the needs of your business. 

In the early days of modern computing, many small entrepreneurs with expertise in a certain area of business would create a software application and sell it.  Today it is virtually impossible for this type of person to participate in the modern corporate world of software with its legal issues and cost of bringing products to market.  We need to bring back channels for wonderfully brilliant people with specific skills and knowledge in a specific area to collaborate with technical people and bring their ideas to the market place in a manner that makes it viable for larger enterprise to adopt their software and integrate it into their systems.

Studying the Modern Enterprise

After leaving the corporate world and working for IBM where I got to see many other companies, I found that over the years while building large scale fully integrated corporate systems that I had become a student of modern corporations.  In this blog I will share what I have learned about enterprises large and small and what needs to be done to address provide a path to the future.  I think you will find my approach different and hopefully refreshing.

There are commonalities in business enterprises that can be represented in computer systems that allow computer systems developers to build very specialized components to handle specific business problems and still integrate into the whole of the modern enterprise. 

To achieve what I am going to talk about requires that a corporation be willing to address its systems from a corporate perspective and allow management of systems from a corporate viewpoint.

If you are looking for detail technical discussions, this is probably not the place.  I will not be able to avoid some technical issues, but the focus is on what to build and how to represent a business enterprise and not how to build it.

The Future

IMHO the future is dependent upon a corporate systems infrastructure that allows vendors to write to standards that allow them plug their systems into a customers system and allow the customer virtually instantaneous advantage of their new system functionality. 

Interestingly enough, I see that we may need organizations similar to the open source organizations to make the vision that I see materialize.  There are major challenges in what I am going to discuss and present along with the development of software vendors willing to create applications that conform to the architecture that I will describe.  The concepts I describe are diametrically opposed to the business objectives of some major ERP vendors.  I do think it is time for a change.

Stay tuned for the building blocks of the future…

Bob Cancilla, Principal
RJ Cancilla & Associates
Office:     916-226-4951
Mobil:    562-290-2849
eMail:    rcancill@mac.com
Skype:    bob_cancilla