You are currently browsing the monthly archive for September 2008.
Sometimes it is a good idea to step back and think after reading the breathless reporting on the Great Left Coast Technology Shows, TechCrunch 50 and Demo Fall . What is most interesting is some of the ensuing analysis. For example, this piece basically says Web 2.0 is dead, because the offered Web 2.0 innovation was yet another photo site, friend network, etc… Even Web 2.0’s death is old news. During November 2006, Web 2.0 was considered as much as dead to be superseded by Web 3.0 (ugh!!! I haven’t got Web 2.0 straight yet).
What is going on? How can I even remotely look intelligent as a technologist going for budget or capital to work with Web 2.0 technology? Dead, not dead, no wait it is Web 3.0. This would make anybody think the IT profession as a whole was psychotic for even suggesting a value proposition incorporating Web 2.0 technology within or without the company.
Perhaps a different view would help put all of the noise in perspective. After recently reading “Engines that Move Markets: Technology Investing from Railroads to the Internet and Beyond” by Alasdair Nairn, one can apply the lessons learned from past cycles of technology adoption to that of Web 2.0. While technologies such as railroads, electric lighting, and automobiles are dissimilar, they all tend to follow the same cyclic steps. One of those early steps is the rise of copycats or “me-too-ism”. Everybody wants to jump on that gravy train with biscuit wheels, and hopes to tap into the investment cash stream moving into the new technology innovation. By gauging where you stand step-wise in the cycle you will know when and where to invest. So in this case Web 2.0 is not dead, it is merely signaling a move to the next stage.
The next stage will be corporate and organizational adoption, not necessarily the next great consumer Web site. The consumer space has been the lead innovation ground for the Internet, with corporate and organizational use trailing. So the consumer space is moving to the later consolidation phase for Web 2.0, while the corporate and organization space is beginning innovation and adoption. Just the announcements by IBM for a social collaboration lab and Oracle for their Beehive initiative show the value of using this cyclic model as a lens for evaluation.
Now is really the time for corporations and organizations to begin to consider adoption of Web 2.0 technology with implementation studies and pilot programs. The potential productivity gains and first mover benefits will be huge for those who can begin the cultural changes necessary. Because the technology drives more of a cultural and organizational change than a true technological change there is little benefit to waiting for the technology to be “perfected”. Instead, the organization’s culture needs to adapt to best practice in collaboration and analytics driven evolution, and where people are concerned it takes time to adapt and assimilate.
Image courtesy of gapingvoid.com
With all the easy to use business intelligence tools and technology we have today, why is it so difficult to create actionable information from the wealth of data in our organizations?
One needs to understand, at a high level, the systems we have built and how they got that way. Your core business systems have evolved over time, budget cycle by budget cycle with no eye towards the overall enterprise. Systems were built to support core business functions – Payroll/HR, General Ledger, Inventory, etc. They were transactional in nature; designed to meet the immediate requirements (e.g. cut payroll checks, track inventory, manage an assembly line, etc.) which did not include getting business intelligence out. Over time these systems became islands of data, popularly known as silos.
Add the fact that silos are structured differently and common data like product and customer is typically not standardized, answering questions across silos is difficult and labor intensive.
As these systems matured, the owners of each silo had departmental Business Intelligence needs. So as budget became available they added a data warehouse or data mart on top of their silo and created something like this.
The result is larger silos with larger sunk investment and still no ability to provide enterprise answers or actionable information. This approach worked for immediate departmental BI needs but if the business asks a question from data that resides in two or more of the silos, getting the answer usually involves a significant IT effort. By the time IT responds the business has gone onto a different question. The business analyst starts gluing spreadsheets together to provide some insight kicking off the next activity in the BI food chain – manual analytics.
Deals that involve Transition Services Agreements (TSAs) turn into our most challenging and satisfying M&A projects. Over the years, we’ve seen (and helped our clients avoid) many pitfalls unique to the TSA situation. Right now, we’re also really excited about the opportunities for creating a lean IT organization and architecture when planning out the strategy for getting acquisitions off of their TSAs.
It’s important to begin vetting out the hidden risks of the TSA during the M&A IT due diligence phase.
1. Assuming that the IT staff of the carved out business unit can evaluate, negotiate and manage the relationship with the former owner during the transition period. Think about this: these are the people who used to take their orders from the parent company. They are good at executing to orders, and they are rarely quick enough to realize that they must now relate to their former bosses as service providers during the transition period. We have seldom seen the right mindset and leadership skills in an acquired company to radically and rapidly turn the tables on working relationships that may go back for decades. If a TSA is on the table, it’s an important component of our IT management evaluation during IT due diligence.
2. Failure to insist on the following key components of a comprehensive M&A TSA during the evaluation and negotiation phases:
- Service Level Agreements (SLAs) – treat the seller as an outsourced service provider, and demand adequate performance. Ask yourself about the quality of service you have received as a PART of the parent company, and assume that they will deprioritize your needs over their own once the deal has closed. You need SLAs and performance monitoring to safeguard against that.
- Definition of Termination Notice windows on a service by service basis.
- Appropriate cost basis for each service offered under the TSA. Caveat emptor - I can’t tell you how many times we’ve seen cost allocations that made no sense in terms of the going-forward business model of the acquired company.
3. Failure to fully plan out Day 1 (day of close) operations. For each business functional area (including core IT services like email and help desk support) make sure there is either an included TSA service offering or a viable internal process and technology component that will be ready on Day 1.
TSAs: The Opportunity
Because a carve-out and the subsequent TSA migration offer the opportunity to create a new operating platform (process+technology+organization) for the stand-alone business, leveraging new technology approaches can result in significant run-time IT cost savings. By relying heavily on Software as a Service (SaaS) solution providers, outsourced hosting and support, and interim strategic IT advisory services, the run-time IT department can be kept quite small, and there is often a reduced need for big-ticket IT leadership resources as the helm. Outside of IT itself, we can design the technology platform to support significant business process outsourcing of non-strategic, non-customer facing transaction processing to reduce other operating costs as well.
We’re excited about this approach because it provides a viable path for driving IT spending down below the current industry average of about 7% of revenue. In addition, it represents the quickest approach to getting off of the TSA. We’ll be laying out the broad strokes of a generalized virtual operating platform in future posts.
In my previous post, I discussed E-Billing and its impact on a Healthcare Payer or Life/P&C/Worksite Marketing Insurer and alluded to levels of E-Billing I’ve seen in my travels.
Level One is the simplest – really just E-Bill Presentment. Sometimes this is a PDF of the bill emailed to a customer (privacy alert!), but usually it’s the customer logging into the insurance company’s web site and viewing a copy of the bill, with the ability to print. On the positive side, this approach does shorten the billing cycle by avoiding the mail. From an IT standpoint, this is a print-driver substitution (I know, I exaggerate, as simply printing a bill is a very convoluted process for many insurance companies), but yes, many companies (and many consultants!) call this E-Billing. From a technical/transaction standpoint, this is the simple equivalent of brochureware for a web site. There is no process efficiency gain by either the company or the customer. The bill goes out, a check comes back. All the manual processes stay in place.
Level Two is a step up, albeit small - E-Billing Presentment and Payment. This method provides the same information as Level One with the ability to submit payment via Electronic Fund Transfer (EFT) or credit card. The lockbox can be cut out and the payment processing steps bypassed, but the payment will again, never match the account by the time the two are matched. Too many changes occur in the gap between bill generation and bill payment.
So it comes down to Level Three, the real payback generating use of technology – RECONCILIATION. In the industry this is called E-Billing Presentment, Reconciliation and Payment. These are the systems where I’m seeing companies and their customers make huge leaps in efficiency. You need three ingredients for this recipe: (1) the back office system, (2) web self-service and (3) true system integration.
The back office system (regardless of brand, platform or computer language) must be kept sterile as the “system of record”. It generates the bills through the application of business rules, dates and rates. The E-Billing System, through integration and custom software, captures this bill and builds a live webpage with embedded links to portions of the bill the customer might need to change for reconciliation purposes.
The customer is notified the bill is available and logs into the company’s website to access the bill at their convenience. Clicking on an employee’s name might bring up the ability to add a dependent to that employee record, or change their employee class, etc., etc., with each change resulting in a modified premium amount for that line item. Links are available to add new employees along with their start dates, invoking a pro-rating routine to calculate the premium. Each time one of the hundreds of possible reconciliation changes are made to the bill, the bill recalculates, the total changes and the change is marked for easy review. Behind the scenes, the system builds a set of transactions representing all of the reconciliation changes. When the customer is finished and the bill is balanced to their satisfaction, they finalize the bill by selecting a separate link. This locks the bill and feed the changes to the back office system through the final set of integration routines. The customer is given the opportunity to pay electronically. The bill and the back office system are in balance and all is good in the land of E-Billing.
What doesn’t happen? A “marked-up” bill is NOT sent back to the company to be manually reconciled. A payment for the wrong amount is NOT posted, resulting in additional debits and credits. Phone calls and emails do NOT fly between company and customer accounting departments. The next bill is NOT wrong before it is generated. Most compliance issues are avoided as the bill controls the census, thereby controlling the premium, so there are no misunderstandings about who was paid when, resulting in a much cleaner claims process.
Of course, the Level Three description above is a very simplified view of this process. There are many, many back office systems, most have been modified since installation and some are even no longer supported by the vendor. Legacy systems abound.
Selecting a true system integrator with expert knowledge of the business is the key.
Image appears courtesy of weblogcartoons.com
Cookie-cutter approaches to integrating platform companies are a surefire way to limit your abilities to achieve acquisition goals. There are many ways to do it wrong, and no single, one-size-fits-all approach to doing it right. Some of the more common mistakes include:
- Letting earnout terms play out in the operating infrastructure for too long. If it’s hands-off during the earnout period, you need to evaluate whether keeping the acquisition on a separate P&L really makes sense after the earnout ends. Too often, these structures persist and limit the company’s ability to achieve full economies of scale by centralizing key functions such as accounting or call centers. Instead of compensating former owners on full P&L, it may actually make more sense to move key functions such as AR and collections into a centralized service model before the earnout ends. It’s important to get these considerations on the table during IT due diligence.
- Assuming that it always makes sense to integrate all of the acquisition’s business functions into the parent company’s model. Evaluate each functional area on a case by case basis. Leverage better and newer technology and business processes within the acquisition. Remember that the most successful mergers are transformative of both the acquirer and the acquired company.
- Assuming that you can just dust off the m&a integration plan for your last acquisition, adjust the dates, and march to the same tune. Every acquisition is unique, and while it makes sense to follow a common integration approach and methodology, flexibility and agility are keys to success.
- On the tactical level, one big mistake we often see is trying to integrate a new business into a business operating architecture that is not adequately documented. Every implementation or transition date for a particular business function/system has impacts that must be defined and communicated to multiple stakeholder groups within and outside the company. Put your entire business platform (people+process+technology) under change control and understand and communicate the changes appropriately.
Designed correctly, E-Bills are a great use for the web, allowing insurance companies to communicate critical financial and census data to their customers in a controlled fashion while increasing efficiency and accuracy for the customer and themselves.
Unfortunately, it has been my experience that there’s a lot of misleading information about E-Billing “products” and “systems” on the Internet. In my upcoming posts, I’m going to wade through this morass of information and detail the approach that works – both from the company and customer standpoint.
The bill I’m speaking of is for group insurance. In the paper world, it’s that complicated, multi-page, already incorrect when it’s mailed, document that details what the insurance company believes the customer owes them. In the group insurance world (especially worksite marketing), where products may be voluntary and usually involve payroll deductions, I contend the bill is always wrong when received by customer due to the nature of the beast. By the time the bill arrives, the customer has employees who have joined the company, left the company, added dependents, etc. The poor customer then moves to try to reconcile said manual bill at a “point in time” that has nothing to do with the insurance company’s computer system used to generate the bill. The customer remits the reconciled (from their standpoint) bill, and it starts all over at the company end. There, it’s a reverse reconciliation as the company tries to figure out the entries the customer made on their end. It’s not unusual to see bills arrive at an insurance company with lines marked out, additions written in the margins, incorrect calculations, etc. How can it be right? The customer doesn’t know the insurance company’s business rules.
A statement about E-Billing products – based on the complexity of insurance billing systems (especially legacy systems), the inherent dynamic nature of the customer’s census and the integration needed to design posting for a true E-Billing System (Presentment, Reconciliation and Payment) back to the billing system after a bill is finalized, products haven’t met the mark. I have yet to see a product that meets the needs of an insurance company requiring true branding, specific process flow, true self-service automation, and SOA compliant integration.
Contributing to this state of confusion, I’ve seen three completely different levels of E-Billing as requested by clients. All are referred to as E-Billing and in many cases, in previous engagements, the client visualized more and received a lot less.
Stay tuned for a discussion of (1) E-Bill Presentment, (2) E-Bill Presentment and Payment and (3) E-Bill Presentment, Reconciliation and Payment (true E-Billing).
Image appears courtesy of graphicalwonder.com
I should be biting my tongue, but the pain exploding in my brain by thinking this prevents me from doing anything further to my anatomy. As one who escaped IBM’s totalitarian regime of the 1980’s (run Apple 1984 Super Bowl commercial), I can not believe I want to return, even if Steve Jobs is cool and IBM was not. Chrome is what is sending me there.
Does anybody think of the poor slobs shoveling coal in the bowels of IT support when they think up a new browser or (shudder!) yet another toolbar. These unsung heroes are just turning the corner on the Safari onslaught — every user with an iPod (99.999998% approx.) had this disease ridden Typhoid Mary installed on their PC auto-magically (thank you for the opt out Apple, not). At least Chrome is “voluntary” at this point, requiring a mouse click for download, but given Google’s track record with their Toolbar, it is sure to be foisted on every unsuspecting PC in short order. I can’t wait.
The best part about all of these revolutionary browsers is playing malware shell games with their developers: “We fixed some bugs, but we are not going to tell you which ones (Ha Ha Ha).” Nothing personal, but what happened to “Do No Evil”? It is an oxymoron, name one marketing/advertising entity with morals (it started with Josef Goebbels and has been downhill ever since).
This weeks Economist has a much more interesting insight in its technology section. The bulk of the world will be accessing the Internet through their cell phones based on cost, penetration, and true ubiquity. This is the platform of the future and the one most in need of innovation and development (the greatest good for the greatest number I always say). Putting all of the resources of the Internet in the hands of the poor and repressed and truly flattening the world as put forward by Friedman seems so right, squabbling over the desktops of the rich developed world seems so Evil (well trivial and venal in any case).
I am not a Luddite (argh! I am having an existential moment), Chrome does have value beyond firing up the trade press and blog traffic (oops, did I say Chrome in my blog too?). It legitimately tries to move the user experience up a level in terms of trying to derive an informational level of interface instead of gratuitous data groveling at a list level. More research needs to move in this direction as the data volumes increase to the absurd. One question we discussed: Would cartoon character representation assist C-level executives understanding? The answer is of course, Yes! Only The Family Guy could illuminate those fixtures.
We work with many clients bringing legacy (pre-web) applications into the modern era. This type of transformation carries with it a series of important concerns and planning requirements that can directly translate into project success.
As with any major business investment of time and money, the reasons for such a move should be justifiable with a series of questions:
- Will this investment make my business more efficient?
- Will this investment make my business more competitive?
- Will this investment reduce future or recurring expenditures?
Although these questions may have seemingly straightforward answers, there are complexities involved in the details that are important to investigate as early in the project planning and scoping process as possible. “Legacy” applications may span a wide variety of user interaction paradigms that do not map neatly to the web.
Migrating from “Green Screen” VT3270 Form-Driven Applications
Migration of these types of applications are generally driven by high mainframe licensing and data center costs, or concerns around being able to maintain a talent pool knowledgeable in the skills required to maintain them.
These types of applications could be easily translated to the web by mapping the forms directly to a web browser. It has been posited that the browser offers little enhancement over VT3270 terminals. With an uninspired and uneducated equal-to-equal translation, some important potential gains can be overlooked or lost, and the project will likely not deliver on its success metrics.
Understanding the user’s needs in this type of application is essential. We worked with an education client where speed of data entry was something that they had with their existing green-screen app, and was deemed an essential requirement of the web-based application.
Knowing this requirement up front allowed us to tailor certain parts of the web user interface for high productivity; ensuring, for example, that particular screens were completely navigable with the keyboard, including the sophisticated AJAX-enabled custom controls.
Providing power users (who are generally big proponents of the existing system) a comfortable working environment in the new system will lead to their being your biggest advocates for change.
Migrating from Client-Server Applications
Migration of these types of applications is generally initiated by a desire to expose internal business practices or content to external partners or customers. Oftentimes, the business has a perfectly good internal business process and software infrastructure built around desktop-based applications and a central server. Problems arise when discussion begins around exposing this data or business process to the outside world, and generally degrades into disputes between the business stakeholders and IT about the best way to accomplish the goal.
These types of migrations usually end up following one of 2 approaches:
- Add new web-based applications on top of a service-enabled enterprise architecture (possibly retaining mainframe systems as part of this architecture) which expose data or business process to the web. This is an evolutionary approach which reduces the business impact on existing internal systems.
- Move the functionality of the client-server applications to the web, by reusing or rewriting the existing business applications on a more modern software stack. This is generally advisable if there are significant deficiencies in the existing software, similar to those discussed earlier regarding older mainframe applications.
Context-Setting Questions to Ask During the Migration Process
The process of migration should allow for time to revisit the business purpose behind the application. In addition to the aforementioned overarching questions about the investment itself, a thoroughly planned application migration should include the following types of questions to generate additional, incremental value over a simple port:
- Has my business process changed since this application was coded 10 or 15 years ago?
- What limitations of the current software are we working around on a regular basis? How could the new application be designed to refine the user interaction process to remove these limitations?
- What are the business’s future growth and expansion plans? How could expansion points be factored into the new application to plan for inevitable corporate expansion or acquisition?
- What types of functionality or data would be appropriate to expose to our partners or customers? What business value would this type of external exposure provide?
The Importance of Data Modeling and Business Reporting
A healthy, holistic approach to migration of legacy applications should start with the portion that arguably has the most value to the business, which is the underlying application data.
Reviewing the existing application data model can identify:
- Legacy content or relationships that can be refreshed or discarded in the migration. This saves time and effort by not propagating data that is no longer relevant to the business, or has been subsumed by higher quality data. This often applies to “reference data” which may be obtained from other service-enabled systems in the business.
- Content that has aged beyond a meaningful date. This data should be considered for archive and purge as part of the data migration process.
- Business relationships that have evolved over time can be re-modeled based on the evolution of the business over time.
Tools and processes around data modeling have improved significantly in the past 10-15 years. Data models can be documented and transformed with little manual effort, and can change relatively painlessly as project planning progresses.
Additionally, existing enterprise-level reporting can be augmented with data from the new application. If enterprise-level metrics don’t yet exist, the context of the application migration process can provide a useful framework for focused EPM planning.
The Reality of the Awareness Gap
It is important to recognize that the stakeholders and technologists of a team responsible for a legacy application may not have the skills or awareness necessary to complete a successful transition to the modern web paradigm.
Effective application migration must incorporate functional and technical education of the web-based environment into which the business is moving. Bringing along all the stakeholders in the process of education and skills training is critical to ensure that the entire project team is aware of the possibilities provided by web-based applications, and begins to think in terms of the web and web-based content.
An effective way to foster an atmosphere of collaboration and open-mindedness is to work through a series of examples of user interface tools and techniques encountered on the modern web every day. Ask users to bring their own likes and dislikes to the workshop, or (even better) screen shots or web sites that they admire. A good moderator of this type of discussion will ask probing questions about what users like, and how they would apply these likes to enhance the application design.
Don’t be Afraid of Technology (or Technologists)
The early engagement of business-friendly technologists in the application planning lifecycle can be critical to the successful build and adoption of the finished web-based application. Technologists bring awareness of application platform features (and constraints) that business users are generally not aware of.
Discussions involving web application architects should focus on review and understanding of the overall application design and business architecture. This type of discussion will result in a web application architecture, which, like a traditional software systems architecture document, will provide a blueprint for high level consistency and delivery of the application and associated development practices.
Unlike a traditional software systems architect, the web application architect’s (citation needed) role is to ensure a series of additional concerns specific to web-based applications are met:
- What is the business software systems environment? What browsers and platforms are in use? Green screen and client-server applications generally had the luxury of a single, consistent deployment platform. Lack of planning in this area could lead to decreased user adoption or frustration if their unique browser does not work.
- Does the web application obey web content accessibility guidelines? Are concerns regarding Section 508 or WCAG accessibility important and addressed? Accessibility to all types of users requires special consideration during web application design, and can be extremely costly if introduced late in the development process.
- Does the business have an international presence? Does the web-based application facilitate this? Limitations of legacy software platforms may have prevented expansion of the business into countries or cultures where complex alphabets or diacritics are required. Moving to the web implies exposure to a significantly larger and more diverse audience, with intricate language and usability considerations.
Business users alone are typically not equipped with the tools required to answer these questions and translate them to technical or software system requirements. Constant and meaningful dialog with high-level technical staff is key to avoid overlooking issues that are unique to web-based applications.
Iterative Development and Feedback
Many business users will feel more comfortable with a large-scale application migration if they are exposed to progress along the path to completion. This can be accomplished through software development lifecycle (SDLC) planning techniques, including a many-phased waterfall approach, or an agile, iterative approach. We have found that the proper approach is highly dependent on the project and the client, and often use a baseline SDLC which has been tailored to the client’s individual needs.
Showing users early and constant progress on the application can keep them informed of what is going on and allow them to have input at the formative stages of the project, helping them understand that it is “their” application.
Measuring Success
A successful legacy application migration to the web will be measured by the answers to a series of questions:
- Does the web-based application improve business efficiency?
- Does the web-based application resolve issues encountered with the legacy application?
- Does the web-based application expose business functionality or data to an increased set of customers or clients?
- Have all users made the leap to the web-based user interface? Empirical feedback from first-time users is critical to identify usability issues and functionality gaps.
While most business application migrations are successful, keeping the goals in mind (and ideally measurable) throughout the process is critical to project success. Success is not measured by a single aspect, but instead a completed recipe that combines ingredients of business, financial impact and planning, and forward-thinking technology.
Yesterday I got all excited about the Chrome release. It is available now for download at http://www.google.com/chrome
After playing around with the new Google Chrome Browser for the last hour, here are some initial thoughts:
- It’s very light weight. It installs in seconds and takes little system resources to run. It is also light on features. More on that later.
- It’s FAST and renders almost every page I’ve tried perfectly.
- I like the new interface which is nice and clean, the tabs on top etc.
- The tools for developers are cool with the task manager providing great system details and even the view source supports code color coding.
- The first page is fine but I find it somewhat annoying that you can not edit the content of the 9 default boxes. Automation is a fine concept but you are not always alone. If I happened to go and check on a gossip site during the day, do I want everyone present in the next meeting when I fire up my browser to know that? some editing functions will be useful.
- It is a beta release granted but even for a beta it is missing some browser staples that have been part of any browser for a long time. Accessibility, content ratings, parental controls, Zoom, Fontsize change all gone.
- Bookmark management is extremely basic
- Passwords. I could not believe but here it was in plain text. If you answer positively for storing you password, Chrome will allow you and anyone else that happens to be sitting at your desk not just to access sites but to view the plain text version of passwords to saved sites. This is bad.
- Surprisingly, no support exists for the Goolge Toolbar but I’m sure that will be remedied soon.
- Lack of support for plugins.
Overall, it is a good little browser that mostly good for casual reading and using the Google tools. It is not ready for the workplace nor can it be a single or even the primary browser for any power user.
It is an impressive first foray into the arena and I hope they beef it up for the actual release if it’s to be a contender
I’m very excited about the news breaking out today of Chrome: the new browser from Google. It will launch tomorrow and you can read all about it on Google’s blog and see their tech friendly comic book(that is brilliant by itself).
I have to admit that both the last release from Firefoxand especially the half baked lackluster IE8 beta from Microsoft were disappointing. While providing relatively minor improvements to most users, they failed to address the biggest challenge confronting the continuing growth of the web: inherent support for rich applications. All we want is to use our email, IM, Search and Facebook without it crashing every few hours taking all windows and tabs with it.
The browser had become the master application where most of our work and play on the computer is done these days. As Google had nicely put it in their blog post “All of us at Google spend much of our time working inside a browser. We search, chat, email and collaborate in a browser. And in our spare time, we shop, bank, read news and keep in touch with friends — all using a browser.” … “What we really needed was not just a browser, but also a modern platform for web pages and applications, and that’s what we set out to build”
So it seems that the smart guys at Google finally understood that if they base their entire business on ads presented while web browsing, they better make sure that browsing experience is fast, secure and continues to flourish. Counting on Microsoft to do that for you is not a smart business strategy.
The new Chrome browser was built from scratch not as a browser but as a platform. Most of the features and improvements are taken form the OS playbook for stability and security: process containment, sand boxing, efficient garbage collection, tight security model.
Here is a short list of some of the innovation the Chrome is introducing:
- Process isolation for tabs and plugins within tabs. Awesome. No more will a single window force me to kill the browser with all 30 tabs I have open gone with the wind.
- New Javascript virtual machine that will product compiled machine code. If Java script is to be the future of rich web interfaces (as opposed to the proprietary Flash or Silverlight) it needs to run fast and be more robust and that’s exactly what the new virtual machine is providing.
- Gears Integration: with Gears support for persistency and OS level access, developers can build client level applications for the web with reasonable portability
- Security: the new security model offers a strong foundation for ongoing security schema that can be used by application coders and plugin providers.
Google will also make the whole thing open source, allow plugins and invites everyone to add and extend.
That’s the kind of innovation we need in order to keep the web growing and becoming the robust platform for work and play.
I can’t wait to give it a full try tomorrow.
