Latest News from JP Morgenthal

Two Critical and Oft Forgotten Features of Cloud Services

Sun, 06 Dec 2009 12:15:00 EST

An interesting facet of advancement is that it tends to limit know-how over time. At one time the mechanic in your local garage could take your entire engine apart, fix any problem and put it back into running order. Today, they can put a computer on the end, read a code, and hope it provides some understanding of the problem. Similarly, the application server revolution has unfortunately led to a generation of software developers that believe that the container can do all your instrumentation and metering for you, thus removing an impetus to build this into the application. These developers lose sight that the container can only tell you part of the story; the part it sees as an observer. If you don't make more internals of your application observable, the most it can see is how often it hands off control to your application, what services your application uses from the container and when you application terminates control. Useful information, but not enough to develop large-scale real world services used by hundreds of thousands, or even millions of users.

My Experience Developing A Google Wave Robot

Sat, 05 Dec 2009 13:30:00 EST

This past weekend I set out explore some of the extension capabilities of Google Wave. One of the weaknesses that have been identified by many is the lack of integration with email. For me, in particular, because Wave is new, many Waves are being orphaned as those playing and testing out Wave don't come back to the conversation for long periods, if at all. My goal was to use email as a means to bring people back to the Wave and keep the collaboration/discussion going in a single environment. Some developers are exploring letting users contribute from email, but in my opinion, that undermines the goal of Wave.

Blogging Is My Civic Duty

Wed, 25 Nov 2009 23:10:27 EST

Why do I blog? For me it's a civic duty. I have an ability to identify the real value of IT investments and directions to business. There's a lot of noise out there coming from sources with their own agendas, both internal and external to an organization, that makes it difficult to fully understand [...]

Desperately Seeking SOA Business Cases

Wed, 18 Nov 2009 11:00:00 EST

Or, to rephrase that famous Kennedy quote, "ask not what SOA can do for you, but ask what you can do to improve your business!" This is a really important question because I believe that the person seeking this information is not alone in attempting to identify real value of investing in Service Oriented Architecture (SOA). The problem is that a properly done SOA should be unique to the mission, goals and processes of the organization making it of limited relative use to another organization. That is, SOA offers a framework for identifying, isolating, delivering and servicing a consumer need, and, while all businesses have some common aspects, the resulting business services should be unique to the needs of that business' consumers.

The Reason Enterprise Architects Should Study Economics

Mon, 26 Oct 2009 16:42:00 EDT

Thus, it is here that Enterprise Architects, especially those we call Chief Architects, truly show their mettle. It is their experience, coupled with the ability to focus on the right set of variables, understanding the impact of change of those variables and being able to communicate that in a way that allows the business to make effective business decisions, which sets top notch practioners apart from Sr. Software Engineers that the organization placated with a title to keep them happy so they wouldn't leave.

My Interview with by Loraine Lawson of IT Business Edge

Wed, 21 Oct 2009 13:26:00 EDT

A couple of weeks ago I did an interview with Loraine Lawson (@lowrain) who covers integration technology for IT Business Edge. There were two different aspects to the interview, one focused on my blog entry "Perhaps SOA is More Strategy Than Architecture" and the other my beliefs on Enterprise Architecture and why I still believe [...]

Response to InformationWeek’s Bob Evans Commentary on CIO Suicide

Fri, 16 Oct 2009 11:45:36 EDT

Bob Evans, senior VP and director of InformationWeek's Global CIO unit, recently published his thoughts and findings on why CIOs should no longer be focusing on aligning IT with business, but instead focusing on aligning with the customer. In this piece, Bob goes onto illustrate how some businesses have done some innovative things to increase [...]

My Prediction of Cloud & SOA in 2005

Wed, 14 Oct 2009 07:00:00 EDT

Okay, maybe it's petty and I'm just tooting my own horn, but I found this old article I wrote for Upstream CIO's October issue (written in July '05). In rereading this article today, I surprised myself how aware I was of the forthcoming Cloud & SOA convergence. The popularity of Service-Oriented Architecture (SOA) is gaining ground [...]

The Role of the Business Analyst in an SOA World

Fri, 09 Oct 2009 12:00:00 EDT

Those of us that are part of SOA-related projects where traditional business analysts (BA) are involved often find ourselves frustrated by the incongruence between the analyst’s approach to requirements gathering and the SOA design. The problem arises because SOA models functionality of a business across multiple boundaries, whereas the business analyst wants to focus on [...]

SOA and Cloud Computing Funding Dilemma

Fri, 02 Oct 2009 16:04:00 EDT

Lately, and primarily among government users, I’ve been hearing about a potential clash of bureaucracy meets technology when it comes to funding shared services. It seems that the current government procurement and funding processes do not favor strategic sharing of software services as an outgrowth of a single development effort. I imagine that this issue might also arise in some large organizations where the business units are funding development using a self-funded IT organization, but I have yet to hear any specific stories coming from the private sector regarding this issue.

Perhaps SOA is More Strategy Than Architecture

Fri, 18 Sep 2009 06:00:00 EDT

On Thursday, September 10th, 2009, I moderated a panel at the 1105 Group’s Enterprise Architecture Conference in Washington, DC entitled, “SOA Goes Mainstream – An Industry and Government Roadmap.” On the panel we had two Federal government agency representatives and two industry representatives, with one of the industry representatives providing a FedEx case study as the basis for their SOA experiences.

Keep Your SOA and BPM Initiatives Separate

Wed, 02 Sep 2009 07:45:00 EDT

This entanglement of SOA and BPM into a single effort is fraught with problems and failure. Each initiative should be undertaken separately and with definitive goals that do not list each other as one of the outcomes.

SOA & Cybersecurity

Fri, 14 Aug 2009 14:15:00 EDT

I recently started my research into cybersecurity and I am working to become more prolific in this area. Naturally, given my inclination to Service Oriented Architecture (SOA), I am really interested in issues related to both SOA and cybersecurity. One thing I noticed immediately regarding cybersecurity is that, in general, there are relatively few experts [...]

Upcoming Speaking Engagements

Thu, 30 Jul 2009 20:11:16 EDT

1105 Government Information Group Enterprise Architecture Conference – 9/10/2009 Ronald Reagan Building, Washington, DC AFEI Cloud Computing Executive Seminar 2009 – 9/17/2009 Sheraton Premiere, Tyson’s Corner, Virginia ZapForum DC: SOA & EA Networking Event, 10/1/09 SYS-CON GovIT Expo, 10/6/09, Washington, DC

When SOA Fails, Just SCA

Tue, 21 Jul 2009 18:15:00 EDT

So, in this morning’s email I received a notification from ActiveVOS that their CTO is a primary contributor to a new book recently released on Service Component Architecture (SCA). Having just recently completed a full investigation into SCA, two things jumped out at me: 1) SCA is heavily being driven by the vendor community and 2) SCA breaks many of the rules of SOA that have been touted by these same vendors for the past 6 years. For example, SCA rewards an implied contract versus a contract-first approach to service development. That is, the contract is derived from the programming model versus defined by the architects.

Sun Was Too Arrogant To Survive

Tue, 21 Jul 2009 07:45:00 EDT

Sure, now that the deed is done and the board has approved the acquisition, there’s lots of Monday morning quarterbacks. However, in this case, I’m not one of them. Indeed, I point to the release of my 9/1997 report that I wrote for NC.Focus entitled “State of Java Report: IBM” and the subsequent press release where I assert that IBM is leading in deploying Java in the Enterprise. The story goes somewhat like this. On the day I released the report, I subsequently released the press release through PR Newswire, but it was also available on the IBM website. Within hours of posting the press release, IBM was contacted by Sun and told to remove the link to the press release on their website. Ultimately, Sun did not like the fact that I presented that IBM was doing a better job of monetizing Java in the Enterprise than Sun was, but that was the truth.

Then What Does Make Someone an Architect?

Mon, 20 Jul 2009 17:45:00 EDT

"Historically, the architect has been the coordinator of all other disciplines involved in the building process. According to training and licensing exams, architects must be able to integrate all building disciplines to protect the overall health, safety, and welfare of a project. We are responsible for not only this integration and the accessibility of structures and their surroundings for human use and habitation, but also for the end result in terms of use, quality, composition, and appearance; engineers are responsible for the application of mathematical and physical sciences, within an area of expertise, and the related health, safety, and welfare. While architects are tested in engineering systems [structures, electrical, mechanical, and site design], building construction materials and methods, codes, contracts, programming, spatial relations, history, and theory, engineers are tested only for specific systems and disciplines. Engineers have a narrow focus; architects bridge the gap between the systems [what engineers design] and what the community needs."

The Impact of Making Product Choices

Fri, 17 Jul 2009 09:45:00 EDT

As part of my job, I help customers to select the appropriate software to either fulfill a need or as a component of a larger solution. Fulfilling this role means comparing similar software offerings and selecting the best fit. The challenge in this goal is to map the vendor offering into a subjective requirement, such [...]

Then What Does Make Someone an Architect?

Mon, 06 Jul 2009 10:15:17 EDT

So, allow me to expand on my prior blog entry — Architecture Frameworks Don’t Make Architects — and answer the question, what does make an architect? To help structure my query, I went in search of a concrete specification that defines the difference between and engineer and an architect and found this http://www.pels.ca.gov/pubs/building_design_auth.pdf STRUCTURAL ENGINEERS may design [...]

Architecture Frameworks Dont Make Architects

Tue, 30 Jun 2009 15:17:56 EDT

So, I was about to blog on this topic when up comes a Tweet from Ron Schmelzer (@rschmelzer) over at ZapThink, Question for the tweeple: do Federal EA Frameworks matter? And how do they stack up against non-Federal EA Frameworks? Do Frameworks matter? Talk about synergies! Obviously, the value of EA frameworks is being questioned by many individuals.

This morning I posted the following comment on the CAEAP website

I see there are work tracks that focus on Enterprise Architecture Professional Learning Framework, value to the practitioner. I think it would be interesting to consider here a move away from a focus on frameworks and a move toward apprenticeship. My personal experience is that frameworks don't help individuals become architects, it just provides a tools for organization of artifacts. Yet, I believe the industry believes that these frameworks (DoDAF, TOGAF, FEAF, PEAF, Zachman) help non-architects do an architect's job.

In my experience, all these frameworks provide a way to think about and organize the artifacts that are part of enterprise architecture, but a framework cannot make you an architect. Additionally, these frameworks provide a means of breaking down the work effort to collect these artifacts, which can be done by non-architects. But, in the end, all these artifacts need to be analyzed against a set of business goals, which then leads to the production of a design that aligns technological direction with the mission of the business.

Which brings up an interesting question, who is using the framework? In some cases, the framework has become a bureaucratic milestone on the way to approval. It doesnt tell anyone who isnt an EA anything more than whats been collected about the current environment. There certainly is no way to ensure that the entire current environment is even fully represented by way of the artifacts that are represented. Its merely a checkmark on some bean counters checklist before releasing funds.

If an EA is using these tools, more often than not they are stymied by the lack of support for emerging architectural approaches. As an exercise, try to find a standard way to capture an SOA design using one of the various EA framework approaches. Sure, people are hard at work trying to retrofit these standards to support emerging architectural methodologies, but these approaches take time and are often years behind the industry.

Most importantly is that enterprise architecture frameworks are designed to be tools. A chisel in the hand of a sculptor will yield a work of art, but in the hands of an amateur yields a pile of rubble. The same is true for any of these frameworks. We need to focus on the creation of architects. I believe the IT industry has been remiss in this effort. Sure, they pay for a few conferences, but architecture is something that is culled over time and based on seeing mass of systems being designed and built. I believe instead of certifications, we should focus on apprenticeships. The resume of an architect should read,

Studied under XYZ from 2004-2006. XYZ has been responsible for at While studying under XYZ I was subject to delivery of the following types of systems.

While Im on the subject, I believe the same is true for cybersecurity experts.

Apprenticeship is a lost art in the world, which is a shame. Our desperate need for resources today has limited our long term vision of what the IT industry needs to thrive 20, 40 or 100 years from now. Business believes systems can be designed like a McDonalds hamburger and that developers and architects are nothing more than the lettuce station and the fry station.

Why do we consistently see headlines, such as SOA Is Dead, EAI Is Dead? Its simple, because all these things are really complex and you cant approach them with an assembly line mentality. Forget Henry Ford already, look at Detroit, learn a lesson people! Focus on developing quality, which means selecting those individuals capable of being architects and supporting them through apprenticeship programs. Moreover, support the creation and execution of apprenticeship programs in your organization.

Architecture Frameworks Don’t Make Architects

Tue, 30 Jun 2009 14:17:56 EDT

So, I was about to blog on this topic when up comes a Tweet from Ron Schmelzer (@rschmelzer) over at ZapThink, “Question for the tweeple: do Federal EA Frameworks matter? And how do they stack up against non-Federal EA Frameworks? Do Frameworks matter?” Talk about synergies! Obviously, the value of EA frameworks is [...]

What's the Best Definition of SOA?

Sat, 27 Jun 2009 23:15:00 EDT

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.

Business' Abuse of IT People

Sat, 27 Jun 2009 12:53:58 EDT

I just want to give a shout-out to all those IT people working their butts off everyday and taking crap for it.

Over the years I've been witness to IT people being abused by the business for not delivering, when in fact, it's the business putting IT in a "no win" position.

One one hand, the business expects IT to make sure that computing resources are used effectively and that costs are kept in check. This includes application procurement, development and computing infrastructure. However, the business also expects IT to not stand in their way when they want to get something done.

Question for the business, "how do you expect IT to keep costs in check and optimize resources when you demand the ability to do whatever you want whenever you want using whatever tools and people you want?"

Look, over the years, I've been a big supporter of IT needing to operating in "business time" and I still believe it is an important goal. That said, one of the major hindrances to this is the lack of adherence to standards where they exist and the end-runs around IT when the business doesn't like the choices IT makes.

IT, this doesn't mean you're off the hook to accommodate the business. Remember, we're here to support he business, not the other way around. You need to pick standards that make sense to the majority of users. Make sure you have done effective enterprise architecture design before making decisions on products and standards; especially products. Don't be swayed by vendors promises. Make sure the business agrees to the value proposition.

Business' Abuse of IT People

Sat, 27 Jun 2009 11:53:58 EDT

The Reason SOA Isnt Delivering Sustainable Software

Fri, 19 Jun 2009 13:27:32 EDT

Wow, to read the positive reviews of SOA and what its doing for the IT industry, one would be likely to believe that theres serious transformation occurring because of this architectural approach. Well, the truth is, implementing an SOA design such that real loose-coupling is achieved and that a service does not share a common bond with any other service down to its roots in persistence and all the way up to its consumers, using todays technology mix, is complex, clumsy and fraught with sandtraps.

I was discussing this topic with a friend the other day who is a big advocate of just focus on the work and stop worrying about the ideology. I know this person knows how to develop maintainable and sustainable solutions, so when he says just do it, I know that implies just do it using common, agreed upon best practices for developing agile software solutions. So, we kept beating about this concept of sustainability and we both finally agreed upon that the key is focusing on understanding the business. This means sustainability comes from analyzing from the top down, not the bottom up as bottom up results in tactical solutions that do not conform to the needs of the business over time.

I know this last statement is controversial. After all, its difficult to accept that if you develop using good component-oriented approaches that you cant retrofit todays bottom up for tomorrows bottom up. But, the fact is that bottom up expresses the how not the why and the how is limited by the subjective reality of the person(s) providing the information. However, truly understanding the business allows the architect to design to an objective goal that can be presented in whatever subjective ways is needed today.

But, lets revisit my opening premise that implementing SOA designs today is complex, clumsy and fraught with sandtraps. I believe the complexity stems from the fact that SOA works best and is most easily aligned with loose-coupling when services are stateless. This means that the service retains no knowledge of the consumer prior to or post usage and has no assumed context of the consumer.

Moreover, a service should operate in a deterministic manner and the consumer should make no assumptions that the service will operate differently based on same context. Most importantly, if any part of the implementation is implicitly linked to any other services or applications implementation, then it may not maintain the ability to switch contexts as needed based on the consumer.

In many cases, statelessness is in direct opposition to the goals of business applications, which are rich in user context and assumptions of their environment. Reporting, security and governance are excellent examples of features that are hindered by moving to a loosely-coupled services architecture and, if implemented in a way that leans too heavily toward one particular applications requirements, limits the services ability to operate in multiple application contexts.

For example, if a service uses a single database table that has relationships with other tables (e.g. foreign keys), and the service has no use for the data in those related tables, but yet the database is going to enforce data integrity when this one table is operated upon, thus forcing the service to be cognizant of those relationships, then loose coupling is broken simply based on the virtue that a consumer is forced to be aware of information that is outside of the scope of the service.

Additionally, there has been a strong emphasis on reuse with regard to SOA, to the point where reuse has become the single, determining factor for defining a service. However, reuse is a completely orthogonal issue to SOA. Reuse is driven by two factors, levels of specialization and interface. Low levels of specialization will drive reuse, however, high-levels of specialization do not necessarily invalidate a service designit just makes it less reusable. An interface is merely the entry point for communication. Thus, we can create reusable components that cannot operate without the consumers explicit knowledge of other areas of the system, for example, a program ID, and because of these constraints disqualify it from being loosely-coupled, and hence, not a service in the sense of SOA.

I believe if you review many of the systems that today call themselves SOA you will most likely find service-enabled applications comprised of reusable software components and Web Service interfaces. Because many of todays SOA platforms do not yet provide the necessary means to really enable true loose-coupling without sacrificing things like data integrity across services, implementing SOA designs today often requires concessions that make the resulting service less sustainable.

The Reason SOA Isn’t Delivering Sustainable Software

Fri, 19 Jun 2009 12:27:32 EDT

Wow, to read the positive reviews of SOA and what it’s doing for the IT industry, one would be likely to believe that there’s serious transformation occurring because of this architectural approach. Well, the truth is, implementing an SOA design such that real loose-coupling is achieved and that a service does not share a [...]

Reflections on America's Conflicted Culture

Sun, 31 May 2009 15:58:22 EDT

Blogging about technology is enjoyable for me. It allows me to explore my interest in the topic, but sometimes, there are issues that just need to be reflected on that have nothing to do with technology.

America is a big and complex country, but culture is something that is usually consistent and prevalent in a geo-political area. Saturday night I was presented with these two conflicting representations of American culture.

"Later on when I got home, I flipped the TV on
I saw a little town that some big twister tore apart
And people came from miles around just to help their neighbors out
And I was thinkin' to myself I'm so glad that I live in America" -- Rodney Atkins from his song It's America

"Greed isn't good! In fact, it's the common thread that runs through all the problems this country faces from financial meltdown to health care to climate change, Americans will do anything to each another for money .... we do it all to each other, the killing and the keeping people sick and poor and in jail and destroying their habitat because a generation ago Ronald Reagan and Gordon Gekko told us 'Greed is Good'. Humans have always been greedy, but they never convinced themselves it was good" -- Bill Maher - New Rules (05-29-09)

I was left with the thought, "will the real America please stand up!"

Is Vendor-Based SOA Training A Good Idea?

Sat, 30 May 2009 13:30:00 EDT

I saw an announcement 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.

Is Vendor-based SOA Training A Good Idea?

Sat, 30 May 2009 11:26:16 EDT

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 [...]

SOA is Dead, No Wait, It's Alive

Wed, 27 May 2009 22:00:00 EDT

I'm currently reading Influencers, in which the authors make a great point that with innovation, the messenger is as important as the message. Theres a story of a researcher who attempts to get farmers to use a more disease resistant strain of corn, but the farmers dont view this person as experienced and dont 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.

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

Tue, 26 May 2009 09:00:59 EDT

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 [...]

The Relationship Between SOA, BPM & EA

Fri, 22 May 2009 21:33:00 EDT

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.

The Relationship Between SOA, BPM & EA

Fri, 22 May 2009 16:33:29 EDT

Architecture is a Craft

Tue, 19 May 2009 14:15:59 EDT

Yesterday, I read Fowlers 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 youre arguing the best CORBA persistence mechanism with Chris Stone of the OMG and before you know it youre 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 its difficult at that pace. Why is this important for an architect? Because theres 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. Its 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. Its known that people hear subjectively based on their own experiences, so when youre 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. Youll 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 dont believe its necessary for all architects to be educators as well.

Whats 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!

Architecture is a Craft

Tue, 19 May 2009 13:15:59 EDT

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 [...]

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

Sat, 02 May 2009 11:02:51 EDT

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 [...]

The battle for cloud application design

Wed, 08 Apr 2009 22:49:10 EDT

It seems there's a battle brewing for the preferred method to build applications in the cloud. There's currently three different models: a) Develop and deploy on my platform, b) develop and deploy in my container and c) deploy your own container/OS stack.

The types of products represented by class (a) include Wavemaker, Yahoo Pipes! and Appjet. The types of products represented in class (b) include Microsoft Azure and Google App Engine -- these products focus on packaging your application and deploying it into an application container. Class (c) is a full operating system platform vis a vis Amazon Web Services. These three different models each offer their own benefits and have their own limitations and risks. Moreover, these three models do not exist mutually exclusive to each other. Indeed, I believe that each model provides developers with differing levels of experience the opportunity build and deploy an application in the Cloud.

However, what is really interesting about these three different models is that the two largest vendors -- Microsoft and Google -- chose to offer an application container model. These are businesses that have focused on building highly-scalable application environments and they have backed the approach that provides developers with a strong services framework, but gives the developer enough freedom to design their application as they see fit. It also seems that this model may offer the best approach to optimization of compute resources. That is, the packaging model allows them to move the application package to any instance of a container but doesn't have to dedicate storage, CPU and memory to the application as is the case with class (c) applications.

Model Sharing Takes Center Stage for BPM

Tue, 07 Apr 2009 21:21:19 EDT

I ran into Keith Swenson and Nathaniel Palmer at last week's SOA Consortium and they brought to my attention some recent advancements in model sharing for BPM. The Workflow Management Coalition has produced a validation suite for BPMN serialization into XPDL (XML Process Definition Language). The press release is here.

This is an incredibly important milestone for BPMS users looking to share a single model across various BPM suites and packages. One might ask, "Why would you do that?" The answer is that not all BPMS applications and suites are created equal. In fact, in many cases, some excel better at modeling, while others might excel at simulation or execution. Some have believed that the long sought out answer to this problem was going to be BPEL, but BPEL only is concerned with the execution aspects of a business process. Yes, it's true BPEL has an abstract notation, but it is far removed from the abilities of BPMN to represent a business process.

Though only 3 of 12 products tested have received certification, there is now a reliable bar that all BPMS products need to achieve and that customers can now demand from their BPMS vendors to support.

Cloud Computing Manifesto: My Observations

Sun, 29 Mar 2009 10:46:44 EDT

Things are getting nasty out there on the CCIF forum. It seems that many, myself included, joined the CCIF believing that it would lead to the formation of an ontology that would help clarify the various aspects of cloud computing and allow the industry to focus on interoperability based on ontological representation.

I was introduced to the CCIF through my blog post calling for classification schemes for SOA and Cloud so that we would have a common terminology to use in discussion rather than using a macro term, which was too encompassing and leading to much confusion and misunderstanding. I posted my thoughts on a classification scheme for SOA at SYS-CON. So far, this article has helped many to better understand SOA in the more formal representation. BTW, my soon to be published SOA, A Retrospective will be one of my defining pieces on SOA and, hopefully, a means of putting back on it's initial path.

With regard to to the aforementioned blog post, I received a lot of feedback from the Cloud community that there were multiple ongoing efforts, one being CCIF. After reviewing what each of the groups was attempting to create and following CCIF for a bit, I jumped in with expectations that work on the ontology was about to pop and create a flurry of activity. What seemingly followed was unexpected. The CCIF was commandeered to promote interoperable cloud architectures versus deliver something to simplify this process. That is, it became a vehicle for vendors to use to push their cloud agendas instead of working on something real.

The Cloud Computing Manifesto is a relatively harmless document. The copy I reviewed has no vendor names and doesn't say anything that would indicate anything proprietary in nature. That said, the backstory behind its creation has made other contributors to the CCIF wary and the leadership of the CCIF suspect.

While I think that there has been some great awareness raised as to the problems of non-interoperable clouds based on the work of Reuven Cohen and others, I believe the CCIF now suffers from a perception problem and the leadership needs to consider that they are the IT world's new version of Rod Blagojevich.

Government 2.0 Camp - Day 1

Fri, 27 Mar 2009 15:05:42 EDT

I attended Government 2.0 Camp today.

Government 2.0 Camp is the unconference about using social media tools and Web 2.0 technologies to create a more effective, efficient and collaborative U.S. government on all levels (local, state, and federal).

Government 2.0 Camp will bring together the leading thinkers from government, academia and industry to share Government 2.0 initiatives that are already in process and collaborate about how to leverage social media tools and Web 2.0 technologies to create a more collaborate, efficient and effective government -- Government 2.0.

Government 2.0 Camp is the inaugural event of Government 2.0 Club, a newly-launched national organization that creates opportunities for government, academia and industry to share ideas and solutions for leveraging social media tools and Web 2.0 technologies to create a more collaborate, efficient and effective government.

I attended sessions on the impact of Social Media Network failures, semantics and mashups and data transparency in government. It's really exciting to see how many individuals, from public and private sector, have vision that social networking, the internet, SOA, Web 2.0, cloud computing, etc. all offers great promise to help transform government. However, I cannot help but to be a bit skeptical that those with the power cannot fully appreciate what is happening here.

One clear factor that cannot be ignored is that 350+ individuals came together to discuss real issues about communicating with the government, how emerging technologies can be used to assist and the dangers of the emerging technology, they will blog about it, they have been Tweeting about it all day and the information is providing food for thought to an audience that is about 100x larger than those that attended. Clearly, how we communicate has crossed a threshold and reverting to more traditional communication means seems unlikely.

Reporting on Strategies and Technologies for Cloud Computing Interoperability (SATCCI)

Tue, 24 Mar 2009 20:48:17 EDT

I attended the SATCCI workshop on Monday at the Object Management Group meeting in DC. Lots of good information and great opportunity to start putting faces to names. It seems there's a growing number of standards efforts arising in the Cloudosphere, which is good, but I still remain skeptical that there's a large enough market surrounding satisfying large-scale computing. That doesn't mean that there isn't a market, but I liken it to GM's first attempt at the electric car. The costs to manufacture and support the car were too high to make a profitable business relative to the number of people willing to buy the car.

One announcement that I found very promising was the release of the DMTF's 1.0 of OVF. This standard not only represents a major step forward in achieving compatibility across virtualization solutions. The DMTF press release lists the following features of the specification:

* Portable virtual machine (VM) packaging
* Optimization for secure distribution
* Simplified installation and deployment
* Support for both single VM and multi-VM configurations
* Vendor and platform independent
* Extensible
* Localizable

Moreover, and one piece that I found really exciting, that is not so clearly stated in this list is that the OVF can be configured to launch multiple virtual machines in a specific order, thus ensuring that an entire service that is dependent upon multiple VMs can be deployed in a consistent manner.

For more information on other presenters at this workshop: http://www.omg.org/news/meetings/tc/dc/ ... bility.htm

Cloud Computing: New Stuff or Legacy Revisited?

Sat, 21 Mar 2009 16:00:27 EDT

There's a lot of information hitting the bitwaves touting the value of cloud computing and it seems that within the IT industry those that profess positive opinions of an emerging market during a hype cycle seem to get more attention than those with negative or pragmatic opinions on the issue. Thus, the hype cycle reinforces itself and the hype grows larger. With regard to Cloud Computing, I've commented before on the two leading opinion groupings--the Gray Hairs and the Newbies. The Gray Hairs look at Cloud Computing as time-sharing redux and the newbies look at it as the only way computing will be done within the next 20 years. Ho hum!

Let's look at what is the same about Cloud Computing:

1. Outsourced hosting - IaaS, HaaS, etc. are just fancy new ways to talk about a model that has been employed for many years now. Effectively, the Cloud provides an economic way to leverage shared computing resources for an economic benefit.
2. Hosted applications - SaaS is just a new way to talk about application service provider (ASP) model, which has been in operation since the 1960's.
3. Disaster Recovery - Even those that have built their own data centers often contract with companies that maintain the necessary hardware and operating systems to enable continuance of operations in the event of a disaster.

Now, let's look at what's new about Cloud Computing

1. Scale - due to the massive reduction in the costs of memory, storage and CPU, we can now offer unprecedented linear scaling.
2. New distributed computing architectures - projects like MapReduce and Hadoop leverage our ability to scale linearly and turn it into an ability to scale exponentially. Linear scale still suffers from an inability to have a 1:1 mapping between storage and memory, thus the speed to read a gigabyte of information limits many of the scaling benefits. Architectures like Hadoop and MapReduce parallelize the access to the data across multiple processors and multiple data stores dramatically reducing this limitation.
3. Virtualization - the ability to leverage a single machine architecture to host multiple operating systems changes the DR costs significantly. In many cases open systems DR costs can be cut by a 1/3 of what they costs prior to mainstream inexpensive virtualization and the development of the hypervisor.
4. Metering - in IT has typically driven by transactions or fixed fees, but, the Cloud treats resource usage like telecommunications industry treats data and voice by billing based on usage, which allows for more affordable pricing models

So, Cloud Computing takes advantage of some of the advances made in computing and combines it with ideas and business models that have been working for the past forty years.

Cloud Computing: New Stuff or Legacy Revisited?

Sat, 21 Mar 2009 11:00:27 EDT

Contrarian or Realist?

Sat, 14 Mar 2009 11:24:29 EDT

On the last podcast with Dana Gardner (http://www.interarbor-solutions.com/), which will be released shortly, Dana commented on my oft contrarian views on information technology. At the time, I took it as a compliment, but it definitely gave me something to consider about myself -- am I a real contrarian for contrarian-sake or am I just an experienced realist?

With all due respect to the analyst community, many are fine researchers, but even those who were practitioners once have been out of the game for some time. Whereas I have taken great measures to ensure that I never have gotten too far away from the actual implementation work. I believe the combined view from both inside and outside the IT universe provides a well-rounded view and one that is full of realism.

Perhaps my analyst counterparts know this, but fear being the messenger, because we all know the messenger gets shot. However, I have always prided myself on "calling it as I see it" and I don't see that changing in the near future.

So, what exactly am I contrarian about? Here's the short list:

1) I believe open source has obliterated the infrastructure software market and this will have negative implications within the next 5 to 10 years
2) I believe businesses will move away from instead of toward greater software quality due to the higher costs and the appearance that it should be cheaper created by a self-serving VC-backed contingent
3) I believe that containers and application servers are responsible for the creation of a entire portfolio of applications that rely too heavily infrastructure and cannot be properly instrumented and monitored. Moreover, I don't believe you can know everything that is required about the operations of the application running inside the container by watching the container. It's like watching a building from the outside and expecting to know what all the people inside are doing.
4) I love learning new programming languages, but I believe the plethora of them make it difficult for businesses to manage their portfolio of applications as an asset
5) Feeding on #4, I don't believe businesses do enough to manage their in-house applications as a proper asset
6) I believe architecture is essential for developing high-quality systems and I also believe that this point is so intangible that it will never be provided appropriate funding from within businesses

That's just a short list. There are probably more, but the idea was to put enough out there to gain feedback. Is this contrarian or realism?

SOA's Closest Ancestor

Wed, 31 Dec 1969 19:00:00 EST

I see many references to SOA being a predecessor of Distributed Object Computing (DOC). I believe this belief is fostered by those that view SOA from the perspective of the service provider than the entire architectural approach.

From the perspective of the service provider, one sees a service contract and relates that to past experiences with CORBA, DCOM, RMI or some other variant of Remote Procedure Call (RPC). In these frameworks, a software object -- something that hides its implementation behind a remotely accessible interface -- delivers functionality to local applications, but is executed across a boundary not directly accessible by the application. On the surface, one could view a Web service as a distributed object, but, this assumption is incorrect, because the facade that the object is really local when it is running elsewhere does not align with a Web service that carries with it the assumption that the service is being access across a known boundary. Indeed, with SOA there is a known assumption that control is being relinquished to the service provider.

It is my belief that SOA is more closely aligned with the concept of publish/subscribe. Pub/Sub was very popular in the mid- to late-90's. Typically thought of a messaging derivative, pub/sub is an architecture that allows one or more subscribers register for notifications generated by a single provider (the service). I've written often over the life of SOA about relationships being the core to understanding the power of SOA. Specifically, my blog entry that analogizes McDonald's drive-up window as a SOA; SOA is an architecture that focuses on leveraging service providers over building the service, but also being able to change service providers without impacting the consumer.

Continuation of the ideology that SOA is DOC further propagates the vision of SOA as nothing more than a modern version of an old classic without the former's complexity. On the other hand, defining SOA as an architectural approach modeled after a very successful messaging paradigm allows SOA to be more fully grocked by less technical individuals and promotes a healthy mindset for succesful SOA initiatives.

SOA's Closest Ancestor

Wed, 31 Dec 1969 19:00:00 EST

SOA's Closest Ancestor

Wed, 31 Dec 1969 19:00:00 EST

SOA's Closest Ancestor

Wed, 31 Dec 1969 19:00:00 EST

SOA's Closest Ancestor

Wed, 31 Dec 1969 19:00:00 EST

SOA's Closest Ancestor

Wed, 31 Dec 1969 19:00:00 EST

Latest News from JP Morgenthal

Two Critical and Oft Forgotten Features of Cloud Services

My Experience Developing A Google Wave Robot

Blogging Is My Civic Duty

Desperately Seeking SOA Business Cases

The Reason Enterprise Architects Should Study Economics

My Interview with by Loraine Lawson of IT Business Edge

Response to InformationWeek’s Bob Evans Commentary on CIO Suicide

My Prediction of Cloud & SOA in 2005

The Role of the Business Analyst in an SOA World

SOA and Cloud Computing Funding Dilemma

Perhaps SOA is More Strategy Than Architecture

Keep Your SOA and BPM Initiatives Separate

SOA & Cybersecurity

Upcoming Speaking Engagements

When SOA Fails, Just SCA

Sun Was Too Arrogant To Survive

Then What Does Make Someone an Architect?

The Impact of Making Product Choices

Then What Does Make Someone an Architect?

Architecture Frameworks Dont Make Architects

Architecture Frameworks Don’t Make Architects

What's the Best Definition of SOA?

Business' Abuse of IT People

Business' Abuse of IT People

The Reason SOA Isnt Delivering Sustainable Software

The Reason SOA Isn’t Delivering Sustainable Software

Reflections on America's Conflicted Culture

Is Vendor-Based SOA Training A Good Idea?

Is Vendor-based SOA Training A Good Idea?

SOA is Dead, No Wait, It's Alive

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

The Relationship Between SOA, BPM & EA

The Relationship Between SOA, BPM & EA

Architecture is a Craft

Architecture is a Craft

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

The battle for cloud application design

Model Sharing Takes Center Stage for BPM

Cloud Computing Manifesto: My Observations

Government 2.0 Camp - Day 1

Reporting on Strategies and Technologies for Cloud Computing Interoperability (SATCCI)

Cloud Computing: New Stuff or Legacy Revisited?

Cloud Computing: New Stuff or Legacy Revisited?

Contrarian or Realist?

SOA's Closest Ancestor

SOA's Closest Ancestor

SOA's Closest Ancestor

SOA's Closest Ancestor

SOA's Closest Ancestor

SOA's Closest Ancestor

Architecture Frameworks Dont Make Architects

The Reason SOA Isnt Delivering Sustainable Software