http://www.avorcor.com/morgenthal/index.php http://www.avorcor.com/morgenthal/interface/feed.png http://www.avorcor.com/morgenthal/index.php Copyright 2009, JP Morgenthal JP Morgenthal en-US SPHPBLOG 0.4.8 http://www.avorcor.com/morgenthal/index.php?entry=entry090630-151756 @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 doesn’t tell anyone who isn’t an EA anything more than what’s 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. It’s merely a checkmark on some bean counter’s 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 I’m 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 McDonald’s 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”? It’s simple, because all these things are really complex and you can’t 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 http://www.avorcor.com/morgenthal/index.php?entry=entry090630-151756 JP Morgenthal Tue, 30 Jun 2009 19:17:56 GMT http://www.avorcor.com/morgenthal/comments.php?y=09&m=06&entry=entry090630-151756 http://www.avorcor.com/morgenthal/index.php?entry=entry090627-125358
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.
]]> Architecture http://www.avorcor.com/morgenthal/index.php?entry=entry090627-125358 JP Morgenthal Sat, 27 Jun 2009 16:53:58 GMT http://www.avorcor.com/morgenthal/comments.php?y=09&m=06&entry=entry090627-125358 http://www.avorcor.com/morgenthal/index.php?entry=entry090619-132732
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, it’s difficult to accept that if you develop using good component-oriented approaches that you can’t retrofit today’s bottom up for tomorrow’s 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, let’s 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 service’s or application’s 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 application’s requirements, limits the service’s 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 design—it 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 consumer’s 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 today’s 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.
]]> Architecture, SOA http://www.avorcor.com/morgenthal/index.php?entry=entry090619-132732 JP Morgenthal Fri, 19 Jun 2009 17:27:32 GMT http://www.avorcor.com/morgenthal/comments.php?y=09&m=06&entry=entry090619-132732 http://www.avorcor.com/morgenthal/index.php?entry=entry090531-155822
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!"


]]> General Musings http://www.avorcor.com/morgenthal/index.php?entry=entry090531-155822 JP Morgenthal Sun, 31 May 2009 19:58:22 GMT http://www.avorcor.com/morgenthal/comments.php?y=09&m=05&entry=entry090531-155822 http://www.avorcor.com/morgenthal/index.php?entry=entry090530-122616 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.

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.]]> Architecture, SOA, BPM http://www.avorcor.com/morgenthal/index.php?entry=entry090530-122616 JP Morgenthal Sat, 30 May 2009 16:26:16 GMT http://www.avorcor.com/morgenthal/comments.php?y=09&m=05&entry=entry090530-122616 http://www.avorcor.com/morgenthal/index.php?entry=entry090526-100059 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.
]]> Architecture, SOA, Cloud Computing http://www.avorcor.com/morgenthal/index.php?entry=entry090526-100059 JP Morgenthal Tue, 26 May 2009 14:00:59 GMT http://www.avorcor.com/morgenthal/comments.php?y=09&m=05&entry=entry090526-100059 http://www.avorcor.com/morgenthal/index.php?entry=entry090522-213329
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, SOA, BPM http://www.avorcor.com/morgenthal/index.php?entry=entry090522-213329 JP Morgenthal Sat, 23 May 2009 01:33:29 GMT http://www.avorcor.com/morgenthal/comments.php?y=09&m=05&entry=entry090522-213329 http://www.avorcor.com/morgenthal/index.php?entry=entry090519-141559 “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!
]]> Architecture http://www.avorcor.com/morgenthal/index.php?entry=entry090519-141559 JP Morgenthal Tue, 19 May 2009 18:15:59 GMT http://www.avorcor.com/morgenthal/comments.php?y=09&m=05&entry=entry090519-141559 http://www.avorcor.com/morgenthal/index.php?entry=entry090502-120251 http://soa.sys-con.com/node/820406). 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?]]> Architecture, Web Services, SOA http://www.avorcor.com/morgenthal/index.php?entry=entry090502-120251 JP Morgenthal Sat, 02 May 2009 16:02:51 GMT http://www.avorcor.com/morgenthal/comments.php?y=09&m=05&entry=entry090502-120251 http://www.avorcor.com/morgenthal/index.php?entry=entry090408-224910
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.]]> Cloud Computing, PaaS/SaaS/IaaS/XaaS http://www.avorcor.com/morgenthal/index.php?entry=entry090408-224910 JP Morgenthal Thu, 09 Apr 2009 02:49:10 GMT http://www.avorcor.com/morgenthal/comments.php?y=09&m=04&entry=entry090408-224910 http://www.avorcor.com/morgenthal/index.php?entry=entry090407-212119 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.]]> BPM http://www.avorcor.com/morgenthal/index.php?entry=entry090407-212119 JP Morgenthal Wed, 08 Apr 2009 01:21:19 GMT http://www.avorcor.com/morgenthal/comments.php?y=09&m=04&entry=entry090407-212119 http://www.avorcor.com/morgenthal/index.php?entry=entry090329-104644
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.]]> Cloud Computing http://www.avorcor.com/morgenthal/index.php?entry=entry090329-104644 JP Morgenthal Sun, 29 Mar 2009 14:46:44 GMT http://www.avorcor.com/morgenthal/comments.php?y=09&m=03&entry=entry090329-104644 http://www.avorcor.com/morgenthal/index.php?entry=entry090327-150542 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.]]> SOA, Cloud Computing http://www.avorcor.com/morgenthal/index.php?entry=entry090327-150542 JP Morgenthal Fri, 27 Mar 2009 19:05:42 GMT http://www.avorcor.com/morgenthal/comments.php?y=09&m=03&entry=entry090327-150542 http://www.avorcor.com/morgenthal/index.php?entry=entry090324-204817
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 http://www.avorcor.com/morgenthal/index.php?entry=entry090324-204817 JP Morgenthal Wed, 25 Mar 2009 00:48:17 GMT http://www.avorcor.com/morgenthal/comments.php?y=09&m=03&entry=entry090324-204817 http://www.avorcor.com/morgenthal/index.php?entry=entry090321-160027
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.
]]> Architecture, Cloud Computing, PaaS/SaaS/IaaS/XaaS http://www.avorcor.com/morgenthal/index.php?entry=entry090321-160027 JP Morgenthal Sat, 21 Mar 2009 20:00:27 GMT http://www.avorcor.com/morgenthal/comments.php?y=09&m=03&entry=entry090321-160027 http://www.avorcor.com/morgenthal/index.php?entry=entry090314-112429 (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?]]> General Musings http://www.avorcor.com/morgenthal/index.php?entry=entry090314-112429 JP Morgenthal Sat, 14 Mar 2009 15:24:29 GMT http://www.avorcor.com/morgenthal/comments.php?y=09&m=03&entry=entry090314-112429