Monthly Archives: May 2009

Is Vendor-based SOA Training A Good Idea?

I saw an [url=http://soa.sys-con.com/node/980029 new=true]announcement[/url] this morning by WSO2 that they are offering free SOA Training this summer; this triggered my “uh-oh” senses. I'm sure that WSO2 means well, but I've noticed a trend in my conversations with individuals who have a predominantly been trained by “SOA Vendors” to focus too heavily on the implementation design factors and focus too little, or not at all, on a top-down approach. To me, this makes perfect sense, because, and I know this is a contentious statement, architecture cannot be taught to the masses.

The results of bottom-up engagements, which are labeled as SOA, are faster delivery, increased reuse and lower development costs—all good things. However, these solutions are constrained by their limited aperture, which results in too narrow of a focus and misses capturing the necessary domain knowledge in to the architectural model—the key promise of SOA—that will provide the aforementioned benefits horizontally, not just vertically in a single business domain.

Hence, the business leaders are disillusioned. It's not that they don't see the benefits to software development, but because they still don't have a solution that enables them to execute in “business time”. Without leading with a top-down design, the necessary subject matter expertise, and subsequent service model, to enable rapid delivery of a large, complex, enterprise-wide business processes is missing. The outcome of this latter point is that as the business tries to reposition with market changes, in the eyes of the business, IT still cannot keep up and all the talk of the benefits of SOA is diminished. Thus, SOA is yet another instance of “all talk, no action.”

But, let's not lay all the blame at the feet of vendors offering training on a skill that is not designed to be learned in a classroom over five days, but is a craft that needs to be honed over years working with talented craftsmen. Part of the blame need to be placed back on the business for believing they can get something for nothing. Much of the business community does not respect the value of architecture, is too focused on tactical wins and allows themselves to believe that they can create an army of low cost programmers, send them to a vendor-led SOA class and have them churn out projects that can meet anything more than a small community of interest's needs.

Of note, I lay a lot of this blame on middle management that has never learned to have critical conversations with their executives. I believe most senior executives are strategic thinkers, which is how they achieved their current position. However, middle managers are not trained to manage the expectations of their executives, and thus, believe if they don't show constant momentum, they will be deemed incapable of delivery and relieved of their duties.

Well, you cannot show current momentum if you've bought into the promise of enterprise and service oriented architectures—you've bought into the promise that strategic modeling of the organization will ensure that the real business needs are met in a way that drives agility and allows the business to keep up with market demands. Middle managers that learn how to manage the expectations of senior management through this process will win in a way that will surely position them for growth.

So, while its been a long and winding path to the answer—subsequently, a path that truly shows how everything is connected to everything—the answer is that vendor-led SOA training is not a good idea. Vendors have a mission, which is to sell software. To them SOA is something you build, not something you design. Hence, the focus from the gitgo is a failure and will lead to continuous disillusionment.

If the goal for the organization is to develop software faster, cheaper and with more quality using CMMI-like processes, then many of these vendors will help you achieve your mission and be successful. However, do not believe for a second that what your programmers and engineers learn in these classes will help at all achieve the mission of service oriented architecture, because, architecture cannot be learned in a classroom in five days; only architectural principles can, which are like sharp knives in the hands of babies if not properly directed.

SOA is Dead, No Wait, It’s Alive, Wait, No, It’s, It’s…Perhaps It’s Who’s Adopted SOA, Not What Has Been Adopted

I’m currently reading “ Influencers”, in which the authors make a great point that with innovation, the messenger is as important as the message. There’s a story of a researcher who attempts to get farmers to use a more disease resistant strain of corn, but the farmers don’t view this person as experienced and don’t want to risk their crop. So, the researcher sets out to find that one person who will try the new strain of corn, thereby, setting an example for all the other farmers. So, the researcher finds this farmer that dresses in Bermuda shorts and drives a Cadillac, who is open to innovative farming techniques and who successfully uses the new strain of corn to grow a bumper crop.

At this point, most of us “engineer” types are thinking, “great, now all the other farmers have an example of it working and will feel more comfortable using the new corn.” I know I will raise my hand with regard to being in this camp, but I got schooled in a big way. I know that when I was out there acting in a business development / sales role for software companies, this was a critical factor for success. Moreover, in certain industries, such as finance, this approach works great.

However, we in IT often focus so heavily on the successful early adopters, that we forget about the majority of middle-roaders and laggards. Why are they middle-roaders and laggards? Well, as it turns out, when it comes to innovation, adoption is sometimes more limited by who adopts first than the fact that it was adopted and worked successfully. Middle-roaders and laggards weigh certain, maybe less visionary and less well-advised, opinions more heavily than the data they can view with their own eyes.

I’ve noticed this phenomenon, but didn’t have a full understanding of the processes that were occurring. Especially with regard to SOA, I remember in the early days being concerned that ITs early adoption of the concept might chase away the business before they had an opportunity to digest the value to them. Sure enough, I believe this is exactly what has been occurring. A concept that was supposed to bring IT/Business together has once again ended up having too heavy focus on IT and the business is now rejecting.

This brings us back to our Bermuda-shorts-wearing-Cadillac-driving farmer. As it turns out the other farmers did not respect this farmer because he was different and because he didn’t think and do things the same way they would. Hence, they rejected the cold, hard data that his crop surpassed them and, as some might say, “bit their nose to spite their face.”

When it comes to SOA, isn’t the Business a bit like the other farmers? If IT wants to succeed at leveraging the power of innovation, whether its Cloud Computing, SOA, Enterprise Architecture, etc. they’re going to have to stop “geeking out” and taking dominance over these creations and allow the influencer groups that the Business listens to take the lead and promote the value of these new innovations.

The Relationship Between SOA, BPM & EA

A colleague recently sent me some IBM propaganda on SOA, BPM and EA. Discussing my opinion of the white paper with him sparked an idea for a blog entry about the my opinion on the relationship between these three methodologies.

Okay, let’s dive into the meat of the issue. What, if any, is the relationship between SOA, BPM & EA? First, some quick definitions:

BPM is a practice that focuses on identifying if a business process is operating within normal operating ranges. How can you tell that? First, you identify some key performance indicators (KPI) that you will use to measure your business process (this implies you actually understand your business), next you have to baseline your current business process; lastly, you modify one variable at a time to see the impact it has on the process. Since this last step can have financial impact for your business, you may want to consider using simulation to assist in this process.

SOA is a practice that focuses on modeling the entities, and relationships between entities, that comprise the business as a set of services. This can be done on a small or large scale. Typically, the relationships in this model represent consumer/provider relationships. Doing SOA correctly implies you are taking a top-down approach. I’ve seen/read views that discuss the bottom-up approach to SOA and I don’t believe the results of that represent SOA. Perhaps it’s a component model, but not a services model. The value of SOA is that you are aligning IT with the business using this architecture methodology.

Finally EA is the ‘Big Kahuna” of architecture practices. It attempts to get the architect(s) to take a holistic approach to thinking about the organization approaches delivery and support of solutions on an enterprise scale. The goal of cataloging and modeling at this scale is that you can see “the forest from the trees”. It’s very easy to think about solutions in your organization based purely upon need, but you will end up with a set of disparate and disconnected silos. Cataloging that need in an EA enables the organization to recognize consistent patterns and consolidate around them. Thus, operational costs are reduced, redundancy is avoided and time is spent solving the unique aspects of new problems rather than continually reinventing the same solutions over and over again.

Now I will provide my opinion on the relationships between these methodologies:

SOA & BPM: SOA & BPM are methodologies, not tools or technologies. It’s irrelevant if SOA suites can do BPMS or BPMS suites support SOA. There is no inherent relationship between these methodologies just because vendors discovered that that they can use Web Services as a means of execute a task within a business process. Web Services is not SOA, it is merely a standardized approach to accessing functionality on remote systems.

However, a well-designed SOA can simplify BPM by enabling rapid business process modeling that only needs to go as deep as identifying the right service rather than having to identify the entire sub-task. SOA can also simplify BPM by denoting in the service the types of KPIs that the service maintains for itself. This requires full understanding that a service is a measurable unit and that metrics are a key component to development of the service contract. If you can’t measure it, it’s not a service!

EA, SOA & BPM: SOA and BPM are views within the enterprise architecture. They don’t replace the need for EA and they cover only a small subject of EA’s requirements.

Architecture is a Craft

Yesterday, I read Fowler’s “Who Needs an Architect” , which is an odd piece that never really answer the question to my liking, but it did get me thinking.

For me, being an IT architect is a full time job that has many facets. One facet is designing systems and applications; this facet is primarily controlled by experience. This facet incorporates requirements gathering, joint application design (JAD) and planning. The more hands-on experience that an architect has, the greater the likelihood that the design of the system will meet the requirements while requiring few modifications to support growth and longevity. This does not mean that we cannot build extensible systems in a generic manner, but ultimately, being able to balance generality with domain-specific knowledge, which requires seeing ten steps ahead, will deliver a system that is most capable for the domain that it is being deployed. This is where I spend the bulk of my time, 65%-80%.

Another facet of being an architect is staying abreast of changes in the field. One day you’re arguing the best CORBA persistence mechanism with Chris Stone of the OMG and before you know it you’re faced with the need to understand the implications of using Struts, Spring & Hibernate. In this field, things change at an incredible pace. I try to spend 15%-20% of my time keeping abreast of emerging technologies and it’s difficult at that pace. Why is this important for an architect? Because there’s a lot of ideology around these tools and they have the capability to speed development, but they also have the equal capability to cripple performance and testing. It’s important for the architect to understand how technology choices will impact delivery, deployment and maintenance.

The final facet of being an architect is relating design decisions to a diverse population of stakeholders, which includes business representatives, peer architects, management, quality control and users. It’s known that people hear subjectively based on their own experiences, so when you’re presenting a vision of the future state of an existing system, or the more difficult, the design of a new system, where there is no experience to pull upon, one wrong word and the sand trap opens swallowing you up. You’ll spend so long explaining your way out of the trap that the entire vision and all the value it brings will be lost. I spend 5%-8% of my time reading articles and books that help with leadership and influence issues to assist with this responsibility. For me, I also do a lot of education as a way of sharing, which includes blogging, writing books and speaking, so I include that in this facet as well, but I don’t believe it’s necessary for all architects to be educators as well.

What’s most important is that I have found that these three facets feed each other. Many architects I know do one, maybe two of these, but I have found that the trinity is what creates a well-rounded architect capable of bringing value to IT processes.

So, to answer Mr. Fowler, architects are critical members of the IT team that lead the efforts to deliver systems and applications for the business that meet their needs in the shortest time frame without sacrificing growth and performance. The business needs them!

What’s the difference between a software component and a service?

It seems that I am not as flexible as I believed I could be on my thinking regarding SOA. I attempted to categorize various SOA engagements in my SYS-CON article entitled “A Classification Scheme for Defining SOA” . I believed that I could hide my dissatisfaction with the lack of clarity surrounding SOA by lumping SODA/application development into its own subcategory. I was wrong! When it comes down to it, there’s still just too much ambiguity surrounding the term service.

So, you might ask, “What is the big deal if we call everything running on a computer a service?” The answer is that not all services are created equally and there’s no way to determine the type or extent of services when a single term is used as a catch-all.

For me, SOA is defined precisely as follows:

Service-Oriented Architecture (SOA) is an archetype—an architectural pattern —that focuses on design of systems from the perspective of providers and consumers as defined by a contract. SOA-based designs introduce agility by enabling interchangeability of service providers without requiring process changes in the consumers. Hence, the SOA is applied at the system level, not just at a single component within a system.

Because I define SOA as an archetype, you can not have a direct instance of SOA, you can use SOA to define a new architecture, which can then be used to create instances of systems. For example, Service-Oriented Integration (SOI), Web 2.0 and Cloud Computing are all architectural types based on the SOA archetype. However, to put things in context, FedEx and UPS, as businesses, are also SOA architectures. Needless to say, if you follow the laws of object-orientation, it’s not invalid to identify an object by it’s topmost ancestor, but in doing so you lose the object’s essence. This is a great technique for lumping things together in a collection, but horrible if you want the richness and value of the object to come through.

Of the three technology-related architectures based on SOA listed above, SOI and Web 2.0 clearly have a strong software connection. Some identify the the software component that has a SOAP or HTTP interface as a service. Well, just as SOA is an archetype, service is an archetype as well, and, indirectly, these software components are services given that they derive from the service archetype.

To better understand my point we need to explore the technical ramifications of this for a moment. With the growth of TCP/IP as a ubiquitous networking protocol, so grew the concept of client/server computing. In client/server computing, a user interface application consumes networked software services to provide data on demand versus having the application exist as a monolithic entity on a single computer. Client/Server computing enabled networked shareable resources.

If I didn’t use the term Client/Server in the above paragraph, 9 out of 10 technical people today would say I was talking about SOA. So, is everyone who is developing systems using Web services today really just doing Client/Server? I believe so, but that wouldn’t be popular, after all, there aren’t hundreds of job openings for client/server architects right now.

[Sidebar Note: What are these people asking for SOA architects really looking for if it’s not client/server experience? From what I’ve seen, it’s typically experience with a particular vendor’s software for building distributed applications. But, to those people I warn you “big mistake”. The underlying standards will not make it significantly less expensive to switch from that tool to another one.]

To summarize, no one who claims to be doing SOA would openly admit they’re just really doing client/server. There is a subset of people doing SOA that are actually focusing on modeling the business as a set of functional service areas (these people are really doing SOA). Then, there’s a bunch of people developing software components using a client/server design pattern claiming they’re doing SOA.

So, I ask you, do you still think that a common definition of SOA is not needed in the industry?