October 2008 - Posts

• True Blue?

  It was then, as he closed the door behind him for the last time that he realized just how much the relied on it - so much that he was no longer necessary. The term "cloud computing" refers to a deployment and use approach that delivers IT-related computing capabilities as services that users access from the Internet. Cloud computing delivers tantalizing features like quick deployment capabilities, useful and open management capabilities, high availability, and system flexibility into the hands of developers and IT professionals. Proponents of cloud computing encourage developers and business users to believe that the tantalizing features, which used to be after-thoughts for most line of business applications, are becoming standard features of newer applications. While I agree that those tantalizing features are finally within reach, and are becoming common - they are not common to line of business applications - they are common in a solution's key aspects. A solution's key aspects form its core delivery capabilities: they work together to - among other features - make deployment easier, provide high availability, and offer open management capabilities. Proponents of cloud computing don't tell you directly that cloud computing is a thin veil that hides the shift of systems management and development from an organization out to a service provider or, worse, several service providers. It is common knowledge that long-term outsourcing fails to deliver business value; as a result, many organizations are reclaiming previously outsourced business functions. Outsourced systems management also fails to deliver business value in the absence of accountability and service level agreements. A service level agreement does not equate to accountability since it only describes penalties that a service provider absorbs as a result of non-delivery of an agreed to level of service. It is often less expensive for a service provider to absorb a penalty delivery instead of delivering on the underlying service level agreement - this common approach effectively transforms a service level agreement into marketing strategy. Most businesses cannot survive on marketing strategies. Microsoft announced on October 27, 2008 the availability of community technology preview of its Azure platform. The Azure platform is marketed as the Windows Cloud Operating System. Azure is easy to adopt because it provides a means to build and user connectors that siphon an organization's data into some data center, to be managed by Microsoft hosted services. Azure essentially shifts systems management and development from an organization out to Microsoft. You should see a pattern by now (of not, refer to the third paragraph). Azure has its place and it's likely to be similar to Amazon's EC2 combined with Amazon's S3. It's likely that Azure will be used to host parts of a solution that need to scale quickly in terms of raw compute capability, serve as a caching capability, or perhaps make it easier to connect web facing front ends to an organizations internal systems. As an enterprise architect, I personally would not use Azure, Amazon, or any other type of cloud commuting service for much more since most organizations prefer to have control of their own applications, licenses, information, and service levels - even at the expense of having to manage all of that on their own. Posted Oct 28 2008, 06:50 PM by Erik with no comments Filed under: Op-Ed

• Oslo: Pipe Dream or Silver Bullet?

  Computerworld's article, Microsoft eyes Oslo as game-changer for application development, provides an overview of the goals of Microsoft's Oslo platform that's scheduled to be released (as a preview) during this month's Professional Developer's Conference. The article focuses on one of Oslo's major goals - to "enable application models themselves to become the applications".  Here are some highlights (all quotes from the article): Oslo allows you to model things in higher-level ways. It allows you to rapidly assemble things Through Oslo, Microsoft intends for developers to spend more time on business intent and less on application plumbing. Currently, developers spend 80% of their time on infrastructure and lower-level details and 20% of their time on business intent. Oslo hides a lot of complexity from the development process Oslo modeling is set to address the additional complexity that concepts such as SOA and cloud computing entail If you have been in the computer industry long enough (as in two or more years - long enough to grasp the realities of software development), you'll notice that the quotes cover most the goals that the computing profession has been striving to achieve for about the last 40 years. While Microsoft's contribution to the cause - so to speak - is likely going to help a lot, their positioning of Oslo is very Silver Bullet-like  - meaning, something that finally addresses issues related to accidental and essential complexity. Like many silver bullet-like solutions, Oslo is an ideal solution for ideal problems. The fact remains that in today's environment architects describe and understand solutions using models and developers use their code to describe and understand their solutions. The reason for the difference is obvious: architects think about the larger picture and compose solutions from other large blocks (databases, other applications, components) while developers think about using much more focused areas of functionality (APIs, platform types, messages) to transform a large arrow labeled "communicate" (on an architect's interaction diagram) into something that actually communicates. It took about ten years for UML to become broadly accepted and used among architects. Despite its broad availability and platform support, acceptance of model driven development is comparatively far behind where UML is toady (UML had, in comparison, limited tool support and practically no platform support despite its broad acceptance. Model driven development is already possible yet its use is miniscule in comparison to it broad availability of tools and platform support). The fact remains that developers like, and need, a high degree of control to quickly deliver functioning solutions. Developers already enjoy the benefits of a high degree of abstraction - essentially allowing them to focus much more on the problem domain (an application's essential complexity) instead of issues related to ‘plumbing' (an application's accidental complexity). Introducing higher levels of abstraction, as Oslo proposes to deliver through its declarative domain specific language, accelerates the descent down the slippery slope of semantics.  Abstractions assume that business users and developers are aligned in terms of semantics. The abstract concept "message" carries many meanings to not only who is interpreting its meaning, but also based on the level of the system where the abstraction is being used. The expectation to model a concept like "message" and have it translated into code (or system behaviour) that meets non-functional  aspects like performance targets, security contexts, and recoverability is a pipe dream. The more robust idea of encapsulation is a proven, reliable means of abstraction for architects and developers. In contrast, model-based abstractions are great for BDMs (Business Decision Makers) because the abstractions are much more closely aligned with how a BDM thinks about a business problem and solution. I believe Oslo will ultimately become another very useful tool at the disposal of system architects and developers, and will be used and deployed as a part of a broader solution.   Posted Oct 21 2008, 07:22 PM by Erik with no comments Filed under: Op-Ed