I Wish I'd Said That

Enterprise Architecture is all about leadership, in fact, it’s more about leadership than it is about IT. Many people talk about EA as the alignment of business and IT. Alignment is a step in the process of EA but not the objective. You have to keep in mind that the EA is driven by the strategic plan of the business so it must be viewed as part of the business not an external entity that needs to say in alignment.

In any existing business there is the concept of legacy. We often refer to legacy systems in IT but legacies exist in all aspects of a business or organization. Many processes, people and even the org chart are or reflect some of these legacies. It is all of these legacy artifacts that are being evaluated when an EA is being considered and this is where the notion of strong leadership comes into play.

It takes strong leadership at all levels to successfully implement any EA. The team that leads the organization, the C-Level folks, if you will, must be absolutely and unequivocally committed to making this happen. This group likely owns the Strategic Plan and therefore must own the EA. Enterprise Architecture is not an IT project that can be pushed by the IT department, it is a business process that requires business leadership. The CIO, the Architects, the Project Managers, the technical teams and the business representatives all must take a leadership approach to the task at hand.

Leadership in this context is more than just sponsorship, it’s really about passion. What makes an EA initiative succeed is the same thing that makes some companies great and that is passion. Many organizations strive to improve but others strive to be the absolute best. It takes enthusiasm, excitement, innovation and creativity to be the best and the same attributes apply to the implementation of the EA.

Next to the people themselves a well crafted EA is the most valuable competitive advantage any organization can have. It is the only component within a business that can simultaneously provide opportunities for revenue generation, bottom line profit increase and compliance improvement.

written by Rob Caljouw

Open source tools and technologies are gaining acceptance in many organizations but a lot small businesses miss out on capabilities that have only been available to larger companies in the past.

Many small businesses believe that open source, although free to acquire, requires extensive IT skills and knowledge to implement and maintain. They often don’t realize that there are many options available to them with respect to open source systems. For example, there are online services that host a number of open source applications inexpensively. Even hosting their own applications is no longer an overwhelming nor expensive proposition today.

Customer Relationship Management (CRM) is something that has long been available to larger companies. Great products like Siebel CRM, now owned by Oracle,and SalesForce.com offer great capabilities but are generally out of reach for most small businesses. An excellent open source alternative to these is SugarCRM. SugarCRM is a very good product and the company offers various commercial packages but their open source offering is a powerful yet simple way for small businesses to get started.

SugarCRM offers a number of installers that really make it simple to get it up and running. I have installed and used SugarCRM on different platforms and I recently set it up on a small Apple machine running Mac OS X Leopard. It took 15 minutes from beginning to end and I had an incredibly powerful CRM application hosted in my environment. Sugar provides complete stack installers for hosts that aren’t equipped with the necessary infrastructure components making it possible for anyone to easily install this powerful suite.

Sugar provides extensive user and administrator documentation making it very simple for anyone to learn, use and maintain the system.

SugarCRM is but one example of the many powerful open source tools available to businesses of all sizes.

written by Rob Caljouw

Last time I talked about some of the dimensions of an Enterprise Architecture and mentioned the principles that are part of the foundation of any EA.

A principle is a statement of fundamental belief. The principles for the use of information and related technologies capture beliefs about the application of information technology to the business. These principles are derived from general business directions, culture and values. Principles provide enduring guides to decision making and form a frame of reference for guiding business decisions related to information technology.

By articulating and publishing principles you can examine and evaluate information-related initiatives from an agreed upon basis. You can avoid discussing each new initiative as though it were the first to ever occur. These principles form a foundation that can be used to evaluate all investments in information. They are not to be slavishly followed without regard for time, cost, or immediate need, but rather are to be used with the wisdom of common sense. If “rules are broken” it is done consciously and with an understanding of what is lost as well as what is gained.

Principles are generally categorized to focus on a particular area such as the organization and it’s business, people and their work or perhaps how information technology is applied in the organization.

These principles are captured as part of a Business Plan for Information (BPI). The BPI represents the IT equivalent of the business strategic plan. This plan consists of a mission statement, the principles, goals, strategies and is a good place to define a glossary. This plan is delivered early in the process and in terms of the business and business users so a glossary is important to ensure consistent and reliable communications as the process moves forward.

This plan is also a good place to capture some Day In the Life scenarios that represent different stakeholders. These scenarios may include activities for executives, operations people, customers or even the operation of some facility.

The principles, however, are what define the core of the plan. Principles are accompanied by statements of rationale and implications. The rationale of each principle derives from the Strategic Plan and the implications begin to form the basis of a set of high level requirements. The implication statements also begin to raise awareness about potential issues that may not have been visible previously.

An example of a principle is as follows:

Category:
Company and Its Business

Principle:
The effective use of information technology is integral to the Company achieving its mission.

Rationale:
As with all other initiatives, the Company must invest in information technology to meet business needs. Our strategic direction envisages a transformed organization with innovation empowerment and increased responsiveness to customer needs. In an environment where expected reaction times are shortening dramatically, many of the significant business changes proposed cannot be made without being able to process information efficiently using information technology.
The way that information technology is used enables or constrains the business process. As a result information technology planning can no longer be regarded as a separate adjunct to planning changes in the business, the two are inextricably linked.

Implications:
The information technology business function operates in partnership with other business areas.
Business planning and information technology planning require each other’s input, which then must be tied to the Company’s strategic plan.
Information technology business functions must be actively involved at the outset in planning and implementing business initiatives.
Information technology people require an appreciation of and understanding of business opportunities.
Business areas require an appreciation of the enabling opportunities presented by information technology.
Information technology requires an appreciation of how technology can help the business achieve superior results.

It is clear from the above example that the principle statement itself may well be directly taken from the Business Strategic Plan or at least derived from it. The rationale describes in business terms what the principle means to the company and why the statement was made. It also states a change in process and thinking whereby IT planning can no longer be separate from business planning.

This type of change is obviously significant and there are implications to a decision of this nature. The Implications noted in the example begin to identify certain new business requirements and processes. The notion of planning in the organization has now changed in a way that sees IT planning and business planning as a partnership. This may have existed within the organization before but it is now documented. If it did not exist before there has been a fundamental change in organizational thinking.

The next article will continue with a little more on the impact of principles and start to look into other aspects of the EA.

written by Rob Caljouw

In my last article I described Enterprise Architecture as a journey. One of the key steps is to define the objective as clearly and concisely as possible but there needs to be a solid understanding of the fact that this will change with time. The EA itself will change and evolve and this evolution of the EA is a recognized part of the process and has to be designed in.

Many methodologies define four components or dimensions of an EA, business, information, applications and technology. The Business Architecture represents a view into the business processes, services and organization. The Information Architecture the business information or meta data and the lower level data structures. The notion of business information here is defined here as data in context. The Application Architecture can be described as the capture and codification of business specific process models. The Technology Architecture represents the definition of the technological components for the delivery of the information and communication systems.

The most interesting part of the EA exercise, however, is the process itself. Each component relies on and requires all the others so the process is critical in the development of the EA. The process must be managed very carefully since you essentially end up with feedback loops within feedback loops it can become very complex very quickly.

Another interesting part of the process is the separation of the component areas. The image in Figure 1 shows a very high level model of three of the key areas of the EA

Figure 1 Information Technology Architecture

The center column that shows the Technology Architecture component actually contains three areas of discipline. Application Delivery, Information Delivery and Technology Infrastructure. The Technology Infrastructure is what many people associate with the Technology Architecture but it’s the Application and Information Delivery portions that provide the foundations for their architecture counterparts. The development of these portions must be done with much rigor and discipline as it is easy to push the boundary into other architectural areas.
A good understanding that the outcome of this process is going to be a suite of standards and practices makes it somewhat easier to keep teams focused on the right thing. This notion of boundaries is what really separates a team experienced in EA development from one just starting out.

The figure above also contains an area often overlooked in many EA initiatives and that is the idea of Architecture Principles. These are a set of fundamental business beliefs that rarely change. They are generally derived from the long term business strategic plan and other sources such as a set of organizational value statements.

In the next article I will start to delve a little deeper into the Technology Architecture and the principles that drive it.

written by Rob Caljouw

I just read a great article by Roger Sessions on Enterprise Architecture (EA). Having worked in this field for 15 of my 20+ years in IT I found a number of his points rather interesting and all too familiar.

The article does a great job describing the top four methodologies but the basic premise of the paper is what caught my attention. It states that 20 years ago a new field known as Enterprise Architecture came about to address two business problems; systems complexity and poor business alignment and the bottom line, more cost, less value. Now, 20 years later, the business problems are; systems complexity and poor business alignment, and the bottom line, even more cost and even less value.

Even after all this time many organizations still struggle with the notion of an EA, some see it as a trendy thing to do, some see it as an IT initiative and some actually think it’s the silver bullet. I’ve even seen many efforts to try and describe an EA in a single sentence as though that may make it more palatable to people. I applaud the effort because that is a very hard thing to do, take a large complex notion and reduce it to a meaningful one liner. I find it much easier to reduce it to one word, journey. A well implemented EA is simply that, a journey.

The most common misconception that I come across is the idea that “we will implement an Enterprise Architecture as part of our IT Strategy this year”. The other misconception I’ve run into is from those that will argue the EA is your IT strategy. The reality is that the EA is a business strategy that is driven by the business Strategic Plan. A great deal of work is done with respect to an EA long before technology even enters the picture.

The problems mentioned above, systems complexity and poor business alignment, are not IT problems, they are business problems. In the context of the article the systems referred to are IT systems. I prefer to view them as business systems as defined by Dr. Edwards Deming. Dr. Deming’s idea of a system includes processes, roles, technology, facilities, controls, people, policies and more. Systems also can exist in the context of a larger system and contain other systems. When you start with this notion of systems then you are far more likely to actually succeed in your EA quest to reduce cost, reduce complexity and get the maximum value from your investments.

written by Rob Caljouw

Welcome to the NoString.com blog. You will find articles about things that I enjoy and hopefully will help other folks.

You’ll find articles about Enterprise Architecture including data, applications and IT infrastructure. I also like to talk about Service Oriented Architecture (SOA) and my experiences with it.

I’m a big fan of Oracle so of course I’ll be talking about them and their technology offerings.

And, of course, let’s not forget about Apple, I’m a big Apple fan, although they frustrate me no end when it comes to the enterprise but I’ll save that for a future article.

written by Rob Caljouw