Architect 2 Architect

Possible Use Cases For Platform as a Service?

2011-06-27T18:00:00.000-07:00

I am wondering if the following use cases qualify for being a first foray into Application Infrastructure Virtualization or more loosely Platform as a Service (PaaS)?

For instance, would I be able to deploy a shared global service that has a wide variety of consumers with different peaks based on the global marketing events cycle each of which could have different provisioning policies. In addition, I am looking for the platform to be able to insure that the commerce site has the ability to honor the QoS needs of its' key subscribers/ top rated customers even during times of unpredictable bursts. So the question is does anyone know of PaaS or Application Infrastructure Virtualization platforms that are able to provide an elastic platform that is capable of scale up and down the compute resource pool based on dynamic provisioning and policy based routing rules without causing service disruption?

In addition, I could PaaS be useful in creating a "shared" prod-like stress/ load environment where by the usage of this environment is governed based on policies that determine who and what gets access to the shared stress environment compute resources. This would enable the business services to also be tested to insure that they are able to optimally use dynamic clusters without "wasting" too many resources in "hydrating" and "persisting" in-process state. Also, key would be to leverage capabilities of the platform to test how the service is able to honor calls from different consumers with different SLAs and service priority levels. Finally, the platform's ability to dial down resource allocation to the business service would come in handy to test behavior of the business service to analyze how it handles lower priority tasks that may be need to operate under resource starvation conditions.

The idea in all cases would be to insulate the business service from having to "hard wire" the decisions of work load and resource management with deployment platform providing the ability to do so just based policies and QoS based resource provisioning.

I am curious to find out what if any experience you have had with the commercial PaaS solutions. Your feedback is invaluable!!

surekha -

Attributes of a Product Manager...

2011-05-29T08:17:00.000-07:00

My fellow blogger wrote about "Should Architects aspire to be Product Managers?" in which he recounts talents like being able to interact with customers, understanding the revenue model, being able to understand and articulate how the technology maps/ aligns with the business strategy, being able to work with a cross-functional teams and so on (8 attributes in total). Strikingly, softer skills of "passion" and "focus" were called out on at least a couple of occasions, two key characteristics , in my opinion shared with the consummate architect!!

Not only do I completely agree with the list my colleague outlines but from experience I can also testify these as key qualities of an good Product Manager. In addition, I have found the following two attribute in a couple of "great" Product Managers with whom I have had the pleasure of interaction. I wish to highlight these qualities as well.

Hence, at nine and ten I propose these abilities. Please read "Should architects aspire to be Product Managers?" for the other eight!!

- #9 - Ability to differentiate between what is core to the product offering and what is not - guarding against diluting the sweet spot of the product.

- #10 - Good understanding of competition and what differentiates this product from competition and if the product is at risk of loosing ground against competition.

Often times, I find Sales Account Managers touting their product as the end all be all elixir that addresses my every need. By contrast, a Product Manager has to be pragmatic about presenting their product's capabilities and pain points that it was designed to address.

Thanks for listening. Please let us know if you agree!!
Surekha -

Innovation - Incubator for "rogue" applications (continued)

2011-05-14T14:36:00.000-07:00

Welcome to the "Architect 2 Architect” blog, Mahi! Awesome first post as well! I am using an unconventional mechanism to reply to your intriguing blog post “http://architect2architect.blogspot.com/2011/05/innovation-incubator-for-rogue.html”.

I am in complete agreement with you on both your dilemma about introduction of “out of compliance’ business solutions into the main stream enterprise technology stack and with your observation that the architect community is in fact at odds with the business in terms of the value prop assigned to these so called "rogue" solutions.

First of, a quick comment on why architects approach these “rouge or disruptive technologies” with skepticism! Architects fear lack of interoperability standards in the new technology, the solutions’ inability to scale, or that there are security loop holes. Architects are also right in verbalizing the business concerns in the pre-production phase which are the very QoS concerns that would plague the business users once the “rogue” solution is in production!! What an irony! Your proposal of having access to these “isolated incubator environments” helps architects in vetting out these concerns without interfering or negatively impacting mission critical business systems. Also, as you propose if this team is made up of a “segment of the enterprise architecture team”, it insures that the architects stay open minded and in touch with both the new age technologies and the business needs!!

Some other benefits of having the architecture community engaged in these “technology incubators” would be that the solutions are created in somewhat of an extensible manner. In addition, architects can use scientific analysis to insure that the technology being introduced through the “rogue” solution is interoperable. If not, the architects can employ mitigation strategies and architecture principles such as loose coupling (i.e. of data and business logic) to insure that the solution is able to scale to meet business growth projections.

Key success criteria for investment in this type of a incubator test bed or an innovative technology SWAT team would be that these technologies/ innovative solutions are adopted as “standards” in time and brought into the main stream. This prevents the enterprise from becoming peppered with too many one off solutions and technology stacks which would end up eroding the initial benefits of speedy adoption. Furthermore, processes need to be put in place to identify when an incubator can be promoted to become a first class citizen of the enterprise.

Clearly, leading technology companies and technology solutions providers have recognized this need. Case in point is the high uptake of technologies that deliver situational apps and "mash ups". The innovative idea of Incubator environments can be used to offer disruptive technologies and solutions a “fast path” to production while offering predictability; demonstrating that speed to market and enterprise readiness need not always be competing goals but complementary ones indeed; which in turn put architects and the business on a common platform.

Fellow architects, please join in and tell Mahi and I if you have in fact implemented the concept discussed in these two related posts! Surekha -

Innovation - Incubator for "rogue" applications

2011-05-14T06:29:00.000-07:00

We, Architects, always have heartburns whenever we talk/think of a system that does not exactly fit into Enterprise Architect and it’s standards. I always struggled with such systems mostly because every time we talk about integration and information/data consistency across the systems this so called “rogue” application becomes yet another system to deal with. And that potentially makes it very difficult because it is not built based on the same Enterprise Architecture Standards rest of the Enterprise subscribes. What’s interesting is, often, business loves such systems.

Few months ago I read a paper (I will try and find the bookmark again) on Gartner that talked about the same topic but had a different spin on it. That got me thinking whether the cause of “heard burn” is simply a matter of being on the same page with business in terms of their expectations from such “rogue” systems. I think these “rogues” are probably an area where Enterprise Architecture should start showing more leadership. When I look around actually many successful & large software corporations such as Microsoft, IBM et al. are taking this approach already under the umbrella of “Technology Innovation”. And I know many IBM Distinguished Architects are behind such successful Technology Innovation Programs.

These so called “rogue” or “innovative” applications may do some of these things, when there is quick “business value/gain”

- How about building few quick PHP based applications in a Java shop
- How about leveraging open source at an Oracle or Microsoft or IBM shop for certain capabilities in a not-so-open-source-friendly corporation
- How about leveraging some of the controversial technologies
- How about introducing web services for a batch-friendly shop
- How about deploying “cloud” for a got-to-be-my-own-data-center friendly infrastructure team
- etc etc

How about a segment of our Enterprise Architecture teams or a Technology Innovation teams (could be partly virtual team) drive such things?

How about using these as opportunities to challenge in-place Enterprise Standards and use as “evolution” for these standards, especially because, we, EAs usually are focused so much on Governance and Consistency we ignore the opportunities to improve.

In short,

Rogue ideas –> Architecture Incubator Platform for these rogue apps –> Technology Innovation Platform that business sees value in –> Force these apps out of incubator once they prove it’s business value into Enterprise Architecture platform –> I believe that’d result in better Business & Technology alignment

What is the definition of a strategic partnership with a vendor?

2011-05-09T09:54:00.000-07:00

In this post I try to outline a few features of what I would consider a strategic partnership with a service provider or a technology vendor. These are thoughts that I have distilled from years of experience (good and bad) with my vendor partners.

Hence this aspect of doing business cannot be overlook and not the least of these is the "cost" of doing business.

Here are a few key attributes, not necessarily in any particular order of preference.

1) the strategic partner relationship has to go beyond a transactional one to that of a more long term one

2) the strategic partner has to have skin in the game - they have to be measured with your success criteria - they can succeed only if you do

3) the strategic partner has to be willing to "share" their technology roadmap with you

4) the strategic partner has to allow you to re-shape their technology roadmap to meet your needs

5) the strategic partner relationship has to include making their test labs, test gear, professional services personnel available to you to expedite a critical path technology prototyping effort or to help test out a strategic technology concept

In summary, I would like to add that a healthy strategic vendor partnership is key to the success of not just a project or a business area (line of business) but also making IT a strategic partner for the business - especially in capturing lost business opportunity with the strategic and timely use of technology - key for this "always connected" social networking world!!

I am curious to hear from you about your experiences to this effect.

Thanks.

surekha -

Time to rethink Application Performance Management - APM 2.0???

2010-02-08T10:57:00.000-08:00

Hi Fellow SOA Practitioners' and Cloud Service Providers -

I am sure that many of you are struggling with monitoing highly distributed services that have stringent business SLAs. I am wondering about how you are managing to tune the performance of the individual components that make up the business service or business process. I feel that there are some key differences that need to be kept in mind in terms of what legacy APMs have to offer to us vs. what we need in these so called next gen APMs that are built to monitor and manage performance of a distributed SOA stack or a cloud based business service offering

Here are some of the salient features that differentiate this APM 2.0 concept from the legacy APMs.

requires to have a deployer or Ops centric deployment view as opposed to a developer centric view
built ground up for highly distributed service based deployments as opposed to the single appliction server container or single JVM based monolithic deployments (the forte of legacy APMs)
should not force a developer of the code/ scripts to monitor potential perforamance bottle necks as the developer is trained to make things work and to have to force them to define monitoring scripts that require a mindset that looks at where things would break (from a communications perspective or from an integration perspective) is inefficient and error-prone
does not force the definition of a per JVM definition of monitoring directives allowing for an highly distributed transaction view or an end to end business process view
provides a visual flow like representation that can be combined with policy based definition of SLAs which has the ability to define SLA tolerance/ compliance ranges
is able to support on-demand run time enrichment/ augmentation of the payload that enables activation of monitoring capabilities on a live system as issues occur (or service execution pathways change) as opposed to predicting these performance choke points at deployment time based in known "execution paths"
does not focus on logging of information and reactive analysis to enable monitors but can be more proactive, business focused and policy based with on the spot analysis capability

Thoughts on this concept or any one has ideas of tools that do what I am looking for?

Thanks for listening.
surekha -

Framework to calculate TCO for Cloud Computing and Virtualization

2009-11-10T17:11:00.000-08:00

To my fellow architects -

A lot has been said about how elastic computing or on-demand computing or cloud computing can be a great cost containment vehicle for companies. The key element there is the pay per use costing model of each of these concepts. If an enterprise is able to predict it's work load and it's usage models then these computing concepts make a lot of sense. The question not withstanding issues such as security, the need to control the deployment environment etc. is in regards to whether these elastic computing models truly deliver on the promise of cost savings and/ or cost avoidance.

Has there been a proven way of calculating the TCO for traditional investment in IT assets that could now be used to compare and contrast the advantages or to identify the hidden costs of these pay per use computing models? I am wondering if there have been any frameworks that exist for doing a cost benefit analysis for even concepts such as Virtualization and Grid Computing. What are some of the elements that need to be plugged into this TCO model to truly get to an accurate figure? Do you include costs associated with "loss of control" and/or "lost business opportunity costs" due to the inability of the cloud provider to scale up an environment during your peak? Is there a truly scientific and proven mechanism, methodology or process that could be used to compute TCO for these newer computing models?

Thanks in advance for your help.
surekha -

Has Anyone realized ROI with Cloud Computing ROI?

2009-09-03T10:52:00.000-07:00

Question to the viewers of this blog is how many have used concepts of cloud computing (and I do not mean private clouds, here)? Are you looking at Cloud computing for reduction in infrastructure costs by moving to a pay as you use concept or to augment your peak capacity or else are you using cloud sofware as a service?

What is your experience and are you realizing the ROI as in a lowering of your TCO, or increase in operations efficiency and availability?

Thanks for your input.
surekha -

Issues with Server Virtualization

2009-08-09T17:40:00.000-07:00

Virtualization has been considered a great way to maximize utilization of server resources by increasing server density. In addition, this concept is considered to be very key to green IT initiatvies as it reduces the number of compute resources needing to be supported in a data center thus reducing the cooling and power costs.

Having said that, there seems to be a performance downside to virtualization. Given that a virtual machine (VM) is yet another layer of indirection the server HW this layer negatively impacts the performance any time there is a need for the application to access IO Channels, SAN disc and other network resources. This is especially so when the application code is either running inside of a JVM or an application server container such as a JEE container, .NET CLR or even a web server servlet container. In all cases, performance profiles of an application seem to vary whether the application is running inside of a virtual layer vs. directly on the physical server.

Vendors are now focusing on this drawback by introducing the concetp of Just Enough OS (JEOS). It remains to be seen how effective these optimizations prove to be in the realm of critical path enterprise systems.

Thank you.

surekha -