I Wish I'd Said That

In the last article about Enterprise Architecture (EA) Principles I gave an example of how an EA principle may have a profound effect on how a business may choose to leverage technology. That particular example represented how a business may view the value of information technology from an enterprise perspective.

As previously mentioned, principles can be categorized in any number of ways but a common grouping is one relating to the people in the organization. This may take on different connotations within the Business Plan for Information (BPI) depending on how the enterprise is defined. A business may choose to define a set of principles based on the core organization and its employees. Another choice, depending on the particular business model, might be to define the organization as an extended enterprise. The extended enterprise may include customers, suppliers and other business partners. In this case principles relating to people may include personnel from these extended entities.

The following is an example of a principle that represents the idea of an extended enterprise:

Category:
Company and Its Business

Principle:
Business partners have access to all business information, save that which is confidential within the organization or to other business partners.

Rationale:
The company collects and maintains significant quantities of information of value to specific business partners and to the industry in general. Our business partners have expressed both the desire and the need to access this pool of information. Our partner service philosophy clearly states that business partners have access to all information of importance to their business except for other business partner’s confidential information. This access to information is a value-added service to our business partners and enhances our competitiveness.
Our Strategic Direction Objective 2: Lead the industry in the provision of timely and reliable services is supported by action program 2.3 “…decide upon and provide information services for . . . the use of our partners . . . that makes our organization more economic”. Information access is a strong supportive thrust to this program.

Implications:
Systems must be capable of providing access by business partners.
Methods to identify and control access to both company confidential and business partner confidential information are required.
Clear definition and context of information is necessary to make the information meaningful to our business partners.
Technology infrastructure is required to connect business partners to information resources.
Business partners need to be made aware of the information available to them.
Information needs to be presented in a value-added manner, as defined by the business partner.

The principle outlined above has extended the organization to include business partners. It has also linked directly back to the business strategic plan objective and action for complete traceability. Another interesting note is that it tied in the organization’s business partner service policy which is also likely derived from the business strategic plan.

This principle will directly impact principles in other categories such as people and their work. If, for example, a category such as People And Their Work contains a principle describing people’s access to information the scope of it’s implications will become much broader because it includes a far larger and more diverse audience.

The following principle is an example of one that affects the people in the extended enterprise and their work:

Category:
People And Their Work
Principle:
People have greater empowerment through ready access to information: when needed, where needed, and in the form needed.

Rationale:
Good decisions can be made by those who have access to, and confidence in, the information they need to act appropriately. The ability to decide effectively is constrained if the employee requires extensive training in or knowledge of the underlying systems used to process the information.
Information needs to be immediately available when the person requires it for the task at hand. It also needs to be presented in a form suitable for the context in which it is to be used. Information technology should be intuitive, so that people find it easy to access and understand information.

Implications:
Information will be accessible from any location.
We will invest in systems that provide ease of use, and to allow information to be summarized, interpreted and presented in an understandable and useful form.
Each person will access information in a consistent way that is tailored to their needs.
Ease of use as perceived by people will be a major factor in design of systems.

It is clear that there will be significant implications and challenges when systems are delivered that will support the above principle. The notion that people have access to information from anywhere, at anytime by any means has significant technological implications for any organization. When you look at it from the perspective of the extended enterprise it presents far more significant challenges.

written by Rob Caljouw

Folks who know me are well aware that I am someone who always tries to focus on standards. They know that my Enterprise Architectures
are standards based, as they all should be, and that working with vendors and products is done late in the process.

If this is the case then why am I such a fan of Oracle, it shouldn’t matter should it? From an EA perspective any vendor whose product line adheres to the standards defined within your EA is worthy of consideration and should be allowed to participate in your business development.

Having said that, when it comes to SOA I just happen to think that Oracle really got it right. There are a great number of vendors out there, both large and small, promoting their SOA tools, techniques and expertise. Many, if not most of them, are very good, there is no question of that but I believe that Oracle is the “best of breed” in this area.

I say this, not from a technology perspective but rather from a customer and CIO perspective. CIO’s face business problems not technology problems and the only constant in business today is change, I know that’s an old worn out saying but it’s still true, so how does a CIO keep up much less get ahead of the curve? Unfortunately you don’t get to pick 2 of the 3 sides of the triangle any more, today’s business demands all 3, everything must be better, faster and cheaper. A good CIO knows that this is not an unreasonable demand on the part of the business units but rather this is the market demand that is driving the business itself. The market forces are changing, the business is changing but the CIO’s situation does not change. They are always in the same place where the majority of their resources (some estimates as high as 85%) are focused on legacy maintenance and integration. This leaves a small amount of their available resources to direct at the all the new demands which in most cases is simply impossible.

So what does the plight of the CEO have to do with Oracle? Please keep in mind that this is just speculation from an outside customer and not based on anything other than my own thoughts. I believe that Oracle, through a series of acquisitions, put themselves in the same position as their customers. I’ve heard other vendors say the same thing but I don’t believe any of them have really faced the same problem to this degree. For example, as a CIO it’s is entirely possible that my organization is using JD Edwards for supply chain support, Peoplesoft for human resources and Oracle for financials and now here is my primary vendor in the same position as me. I have to admit, at this point I’m laughing pretty hard and saying, welcome to my world.

While Oracle was buying everything in sight I had been evaluating a number of approaches to solving the problem in an organization and after a lot of research it seemed that SOA was a very viable solution. We had done a lot of work with web services and other components of SOA in the past so it made sense for us and really was a pretty simple decision. I then looked for the best of breed in the SOA arena to and settled on Oracle. They were not just providing a set of tools to get their customers started on the SOA path but they were also adapting and extending their entire product line using the same tools and techniques.

As I mentioned, many vendors claimed the same strategy but no one did it as extensively as Oracle. They also did it in a customer friendly way which I, as a customer, really appreciated. If I had adopted SOA as a strategic component within my EA then Oracle was a good choice for applications and development tools since that was their stated direction. If, on the other hand,I didn’t care about SOA but wanted to just continue business as usual with Oracle Financials for example, that path was also available to me. Even if I don’t use any Oracle applications at all but I just want to move my infrastructure to a SOA for better legacy integration and new process implementations Oracle is a great choice.

written by Rob Caljouw

Is Service Oriented Architecture living up to the hype? To me that’s a rather strange question but it seems that some folks are asking it so I suppose it deserves an answer.

According to Accenture CTO Donald Rippert, as described in this article on cio .com by Paul Krill, the answer is no. After reading the article, however, I can certainly understand why, from his perspective, this is the case.

The sub heading of the article basically says that if CIO’s don’t deliver on the promise of SOA it will become another over hyped and underused technology. First of all, SOA is not a technology, it is, however, a standard from the OASIS consortium with a reference model. I know this a common misuse of the phrase but from folks supposedly in the know I sometimes expect a little more.

The article describes what Mr. Rippert sees as the four phases of a SOA implementation:

1. using XML as an interface;
2. implementing legacy systems as Web Services;
3. using an ESB to connect Web Services and use composite processes; and
4. using BPEL in which a business application is revised by making changes to the process model rather than the code.

He then says that SOA is not enabling this today. I would suggest that SOA does indeed enable all of the above but if you take that particular approach at the wrong level you will be disappointed. This describes one of many possible ways to leverage an existing legacy component within your SOA initiative but it has little or nothing to do with an enterprise SOA implementation.

If you decide to leverage an existing legacy function because it makes business sense within your SOA initiative, you may or may not decide to use XML as a data exchange format. You will likely expose the legacy component as a web service. Again, you may or may not use an ESB to connect to the service but it will probably end up being accessed through the appropriate business process implemented in your BPEL environment.

On the other hand, if this is meant to describe an enterprise approach to your SOA implementation it makes little sense. To simply decide that XML is the answer to all interfaces and that all legacy systems are to be implemented as web services that will be connect through an ESB and then plugged into a BPEL process seems rather foolish. If one were to attempt such a thing and actually succeeded they would have a great deal of complex technology layered on top of an existing legacy environment with little or no value added.

If SOA is seen as a silver bullet then it’s not going to work. If people understand SOA for what it really is and they have a solid grasp of the real business needs and drivers then they are well positioned for a successful implementation.

So back to the original question, is SOA living up to the hype? My answer is, who cares? As a CIO my questions have little to do with hype and a lot to do with delivering extensible, scalable, high availability systems in support of a business that is growing in multiple dimensions. So does implementing a SOA as part of my Enterprise Architecture enable me to deliver this type of environment as part of a growing business? The answer to that question is absolutely yes.

written by Rob Caljouw

I see Oracle has given everyone a nice Christmas present by releasing the latest preview for the 11g SOA Suite. It is the SOA Suite 11g Technology Preview integrated into the JDeveloper 11g Preview 3 so one single install now includes everything.

You can download the software from here. You will find the documentation, tutorials and other collateral materials here.

I’ve just installed it on a couple of my Mac’s, a MacBook Pro (Intel) and a G5 PPC Desktop both running Leopard and so far everything looks great. I started the WebCenter Preconfigured OC4J and created a database connection to an instance of Oracle XE running under Windows XP inside Parallels on the MacBook Pro.

If you want to try this I suggest you set the environment variable JDEV_USER_DIR before you run JDeveloper for the first time. This version creates the directory JDeveloper under “~/Library/Application Support” by default. If you try and run the WebCenter OC4J it will fail due to the space in the path. Just set JDEV_USER_DIR to point to the directory of your choice and fire up JDeveloper with the jdev script in $ORACLE_HOME/jdev/bin. I set the JAVA_HOME variable but I still had to edit the External Tools setting for it to find the java executable. Just go to Tools -> External Tools… and change the Arguments list from:

/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/..
to:
/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/

I’ve loaded some of the demo schemas into the database so it’s time to work through the tutorials to try out some of the new features in this release.

written by Rob Caljouw

Many businesses lately are concerned with the notion of alignment between the business and IT. I would suggest that although it appears to be a worthy goal it is the wrong approach to resolution of the issues they face.

Alignment by definition implies more than one entity and therein lies the problem. A common view is that there is business and there is IT and the goal is to align them. The problem is that if you see “the business” and IT as separate entities then the alignment mechanism between the two becomes yet another entity that has to be managed and maintained. One of the goals of most, if not all, organizations is to reduce complexity. Whether it takes the form of process analysis, process engineering or process re-engineering the goal is the reduction of complexity. The outcome of any alignment initiative, however, is added complexity and therefore a rather large step in the wrong direction.

Alignment usually comes down to trying to align IT projects with business objectives which is simply doomed to failure. Everyone is aware of the high percentage of IT projects that fail, there is certainly nothing new in that. The real problem here is that now if an IT project fails what happens to the business objective if they are tightly aligned? This is not to say that alignment initiatives will always fail, just as not all IT projects fail but it certainly introduces a high level of risk which, again, adds to the complexity.

Convergence, on the other hand, is a better approach to the problems at hand because it indicates that the entities will come together at some point in the future. This is the real objective I believe most organizations are striving for. I’ve mentioned in other Enterprise Architecture (EA) articles that the EA is driven from the business strategic planning process. This can only work if the business and IT are really a single entity. If companies focus on the convergence of these entities instead of their alignment they will arrive at the right destination and they will get there more quickly. This is also a far simpler exercise than the task of alignment. In fact, simply put, convergence is attained when the enterprise acknowledges that it is in the information business. Now, granted, this is a vast simplification but nonetheless it is an immensely important first step and once this realization takes place things get considerably simpler to deal with.

Most businesses are quite adept at understanding their priorities, managing governance, creating measurements and metrics for performance and working with cross functional teams. This same skill set applies equally in planning and execution with respect to IT. Given this, a “converged” organization is well positioned to properly deal with what is really important; governance, strategic planning, investment management and enterprise architecture.

written by Rob Caljouw