Saturday, December 31, 2011
Tuesday, December 13, 2011
- Develop an enterprise strategy and roadmap
- Educate everyone on what is happening and why
- Buy 3rd party education (computer based training) on the basics of cloud and require everyone to take the classes, even the business people.
- Create a cloud council with representatives from all the constituent groups to act as a clearinghouse for questions, collection point for input, and distribution point for sub-strategies.
- Bring in skilled 3rd parties to augment your team because no matter who you are you don't have enough in-house cloud knowledge.
Friday, October 28, 2011
- A SAS 70 Type II attestation is about financial controls, not operations, not security. Therefore if something does not impact the finances of a company it is considered out of bounds for the audit. Remember the AICPA (American Institute of Certified Public Accountants) governs the SAS70 auditing standard. I respect accountants and auditors but I have yet to find one who I can't make their head spin with technobabble.
- There is no standard for the contents of the attestation. The SAS 70 contains self reported financial controls. Therefore each company, by shopping for an auditor, can intentionally omit germane information and still have an attested report.
- The attestation report is not available to non-customers by rule. If it is shared with a customer it is a violation and that alone should make someone wonder. Even as a customer there is often a significant cost associated with getting a copy of a SAS 70 audit report (in the tens of thousands of dollars based on my experience).
- The attested report simply validates that the organizations does what it says it does. During the audit it is possible to obfuscate issues because the audits do not contain a significant amount of process execution observation.
Friday, October 21, 2011
- software library support
- level of coupling (operating system, libraries, other applications, utilities, etc.)
- component versioning
- development, test, qa, and staging environment setup and certification
- test cases and automated testing
- testing of the application and its associated components and certification
- migration to production
- training of developers and testers
- update of disaster recovery plans
- update of systems management services (monitoring, troubleshooting, backups, etc.)
- Establish a framework - define an application framework to align redevelopment and future development with the growing capabilities of a cloud, even if only a portion of the cloud functionality is available.
- Challenge conventional thinking - there is no reason to assume clouds cannot benefit siloed applications, mainframes cannot participate in a cloud, CICS applications cannot be executed in a cloud, or that the end game is even cloud (it should be delivered value).
- Crawl, walk, run - learn from the first efforts and cascade that learning into following efforts until an optimization loop becomes part of the DNA of migration projects.
- Components or Containers - for each application determine whether its better to componentize, optimize the application for the new environment adopting a SOA model, or containeraize and keep the application isolated as a whole solution perhaps using web services to map inputs and outputs extending the reach of the application. In an earlier blog post I provide four options to handle legacy applications.
- The learning curve - architects, designers, developers, and testers will all need to relearn significant parts of their job. If internal development is a core need make sure the necessary skills are identified, quantified and present within the teams.
Saturday, October 1, 2011
- Vertical domain expertise will be required for those in IT who want to be on the forefront of the revolution
- As a revolution I believe the critical mass will be reached rapidly and therefore believe the change will occur over the next 8-10yrs
- Cloud computing will help drive this change
- A natural synergy is the decoupling of internal technical expertise from its application which has hindered companies for decades from making great leaps
- Legacy systems will not hinder the revolution because they're already in the mix due to the issues of cost, complexity and compliance
- Demographic challenges in finding qualified people will drive the consolidation of positions that used to be split between the business and IT
- Companies who get it right will benefit so tremendously they'll never turn back
- The shift is already underway!
Thursday, September 15, 2011
Monday, September 5, 2011
Wednesday, August 31, 2011
Monday, August 22, 2011
Sunday, August 21, 2011
First Lesson: enterprise transformations are not a re-branding exercise
Day one I knew the project's scope did not reflect its challenges. The client was using the project as a way to effect an organization wide transformation to become a better customer focused company. Transformations require the support of senior leadership, investment, and the acceptance of risk. Visions of a better future need to be seeded with the executives and given time to germinate, with the hope passion will build within each leader to make the future happen. Instead we had the feint, background support of some in the C-suite, tepid support from IT at best, and a range from lackluster acceptance to abject opposition from the lines of business.
Second Lesson: any transformation requires a well thought through and defined strategy
Without the support of the executives, the vision was empty. As a result nobody wanted to participate in developing a strategy for the transformation. And without buy-in and a strategy, there was nothing in place to guide the project as it hit critical junctures. Often during discussions drilling down on a particular topic, nobody could articulate details on what needed to change, how, when and who would be the owner moving forward. Without a target future state we found there was nowhere for new responsibilities emerging from the transformation to land. This caused significant friction as we were on the clock, expected to make progress, but everything we did was dependent on client resources providing guidance and making decisions
Third Lesson: transformation success requires talent
All three client resources portrayed themselves as experts in the ECM space when, in reality, their knowledge was limited to content creation. In fact it was this arrogance that created the foundation for the technical challenges. And driving inexperienced, incapable people to work long hours cannot create success out of a vacuum.The client project leader was ineffective at providing input to the timeline and managing client tasks. Due dates were treated as meaningless and repeatedly missed without acknowledging the subsequent impacts to the timeline and cost of the project. The client subject matter expert was an off-site third party consultant spread extremely thin whose goals were not always aligned with our customer. The client technical leader was a junior resource with no architecture, web or application development experience who was quickly relegated to the role of a go-fer.
Fourth Lesson: success does not end with the sale, it requires client satisfaction throughout the project
Based on the above items there was more than enough reason to not accept the risk of the project, or run away when SOW negotiations continued for months after the project was already underway. But revenue generation was necessary as part of the business case for promotion, so the engagement lead ignored the concerns of his team.
Fifth Lesson: risk is inherent in every project, but it should be limited and managed
The engagement leader spent 1-2 days per week on the project but refused to listen to the highly experienced, dedicated directors on the ground every day. Blind to risks, within days he made four core decisions which pushed the project to the edge of the cliff for the remainder of its life:
- dismissed concerns about the missing customer strategy inability to articulate requirements
- used inexperienced, off-shore application developers for an on-site web overhaul and content management implementation
- delayed engaged the ECM platform expert until the statement of work was signed, which didn't occur until four months into the project (two months too late)
- accepted new responsibilities that required client level decisions
Sixth Lesson: communications must be transparent
The client had no reason to believe the decisions of the consultant threatened project success because they were never informed. In fact they were insulated by the engagement lead who closely managed and controlled all information shared. Regardless issues raised by the consulting team, the message to the client was everything is normal and manageable. As the growing gap between expectations and delivery became increasingly difficult to mask, the engagement lead pushed the team to be "creative" and find ways to make progress. Doing so quickly degenerated from difficult to impossible. The team looked busy, but very little of the work actually progressed the project.
Seventh Lesson: take responsibility
Among the directors we knew we were out of options. However because the engagement lead was also the best friend of his leader, and the engagement lead had driven a wedge between us and the client, we focused on trying to make it work. We should have documented our concerns and requested a Quality Assurance review. We had the right to, but doing so would also put our careers in jeopardy, especially considering the reputation of the engagement lead. We shirked our responsibility and it came back to haunt all three of us repeatedly.
Eighth Lesson: know what you're getting into
To make it a perfect storm, the underlying technology had it's own issues.The ECM platform used by the client had a unique architecture and implementation. Since many members of the consulting team had prior ECM experience, we used that experience to drive estimates. And because the platform was new and relatively unknown, it was difficult to find expertise. It took several months to identify an expert and then several more for approval to get the person on-site. And because the project had been budgeted to use off-shore resources, the cost of the expert pushed the project even further over budget. On-site, we worked with the ECM platform expert to address significant issues with the existing implementation. He was able to validate my architecture as the correct approach, a contentious point with the client experts from the start which had stymied progress. His documented expertise, supported by the platform vendor's own testimonial on his brilliance, wasn't enough. We had to make the changes we knew were right and then show the client why it was better than their way. Of course this didn't help our timeline, nor budget, but it was effective. We essentially discarded the existing slow, unsupportable solution for a streamlined, very fast, very extensible implementation. Luckily our new direction changed some of the requirements enabling us to finally use those off-shore resources.
Unfortunately the client was in too deep to walk away or choose a different partner. Follow-on projects made few changes for the better. The engagement leader continued to focus on revenue at the expense of people and the truth.
From a deliverable point of view, the project is viewed as a huge success. It delivered a better mouse trap and, for the first time, made the company appear to be integrated. However, as predicated on day one, it wasn't enough to appear integrated so the net impact on sales was negligible. The project grossly overran it's budget. Two of the consultant directors lost their jobs. Several on the implementation team were given unflattering ratings as a way to spread the blame. The executive on the client side was terminated and their team took a reputational hit.
And what happened to the consulting engagement lead? Well of course he got that promotion, and a huge bonus.
Friday, July 29, 2011
Wednesday, July 13, 2011
Monday, June 27, 2011
Monday, June 13, 2011
Sunday, June 5, 2011
- Willingness to learn
- Desire to be broadly experienced rather than a specialist
- Appetite for risk
Monday, May 2, 2011
- Enterprise Cloud Strategy development
- Migration costs
- Application development costs
- Learning curve
- Disaster recovery effectiveness
- Success metrics
- Accounting, Tax, and Finance change
- Legal impacts
- Data integration
Monday, February 21, 2011
Today it's a blind spot we survive by luck and hard work. In the cloud with it's ability to rapidly scale and morph, that blind spot will become a killing field with the careers of well intended but unsupported IT experts littering the ground.
Wednesday, February 9, 2011
We need to raise the bar!
- Some will be held accountable for not researching and implementing these technologies when they started appearing in the 2001-2005 timeframe. Think of all the lost value that accumulated over the five year period from 2005 to 2010 as companies ignored cloud.
- Many will simply be outpaced by their younger, nimbler competition who understand that CIO's need a balance of skills and can operate as their equal on the business side while still having deep technology knowledge and experience.
- Most will be held accountable for a series of failed implementations because they waited to long or never did develop a cloud strategy. So many of the implementations today have been built to a vision with no supporting strategy. Already companies are scrambling to remedy siloed cloud implementations and rationalize multiple instances of the same cloud service.
Sunday, February 6, 2011
I equate vendor lock-in to anti-cloud. The entire purpose and value proposition of cloud rests on it having dynamically defined borders. Such an open architecture requires, by nature, strong standards to facilitate the interchange of data, processes, and policies. However underscoring the lack of available expertise in the market and the willingness of leaders to attack without understanding, companies are moving headstrong with short-sighted tactics (I dare not call them strategies for the amount of thinking support the tactic is barely enough to call it more than a whim!). Companies are simply mortgaging their future for benefits today.
The landscape today is Private Cloud. I have yet to see interoperability standards proposed by or supported by a Private Cloud vendor, whether a software provider such as VMWare or a service provider such as Amazon. It was only a few years ago where the cost of virtualization software was so high it was cheaper to add physical servers. Adopting a proprietary platform today is likely not only to lead to higher overall costs, but solution isolation without the adoption of interoperability standards.
As is most often the case I believe it will fall to the open source world to define, build and adopt open standards. Xen came in to existence to duplicate VMWare without the high cost, bloat, and closed architecture. Look at what Amazon AWS has done with Xen! A full slate of tools of in development in the open source community along with improvements in open source operating systems which will subsume many of the capabilities paid for in VMWare, Hyper-V and other solutions today. What today is a service or software will become a component and foundation.
I'm not ready to short the stocks of EMC (VWWare's parent), Microsoft or Citrix (owner of Xen), but I'm watching closely!