Oh wait...it's only June 30th. Wow. I sure feel like I've tried to cram twelve months of work into six months of time (with varying levels of success). And sitting here at 2010's halftime show, I wonder what the second half will bring.
But before we spend too much time plotting our second-half strategies, let's look back at the first half's highlights.
Lately I have been getting quite a few inquiries on database migrations asking me about migration approaches, best practices, and tooling. Some of the reasons why companies are looking at migrations are because of staffing issues, scalability and security concerns, and cost-saving strategies. Migrations have always been complex, time consuming, and expensive, because each DBMS has proprietary data structures, data types, and SQL extensions. Once you choose a DBMS, you get locked into its platform, often creating a challenge when looking to migrate. Some companies told me that it took them more than a year to migrate some large and complex applications, which is not surprising. Although, tools and services have helped with migrations in the past, they have not been comprehensive and automated, which would make the process simple. Like an IT manager in the retail sector recently told me, “We did not want to spend a million dollars on tools and services just to save a million dollars on our database platform; it just didn’t make sense.”
Recently on a cross-country flight, I was just waking up when the flight attendant asked me what I wanted for lunch. She was a little annoyed because I kept her waiting while I looked through the magazine for food choices, and gummed up the whole works. And who could blame her for being annoyed? She had a whole bunch of people to get serve. I made a hasty selection and mistakenly picked the healthy snack box (organic pumpkinflas granola and apple slices instead of pepperoni and a chocolate chip cookie).
About an hour later, I had some serious hunger pains and would have killed for one of those old-school gummy chicken casserole airline dinners.
What would have solved this? A proper online engagement architecture, naturally. I usually print my boarding passes out ahead of time. So why doesn’t an airline print out the food choices under the boarding pass, or distribute via mobile devices as people increasingly use them for check-in? The airlines could provide other information, too, like how full the flight is, and whether NBC in the Sky will show something good like “The Office” or something not-so-good like “The Marriage Ref”.
So, what’s the problem? Content management and delivery systems aren’t unified. There are all kinds of opportunities to present rich, consistent, engaging multichannel experiences by integrating technologies such as content management, customer relationship management, document output management, email campaign management, and others. But these are still siloed, due to legacy issues as well as market dynamics (there is no unified solution on the market).
Applications development people can't stand the Luddites in the operations group, and ops people hate those prima donas in apps dev - at least that's what we are led to believe. To explore the issue, two of my colleagues who write to the infrastructure and operations (I&O) role - Glenn O'Donnell and Evelyn (Hubbert) Oehrlich - invited me to participate in an experiment of sorts. They arranged a joint session for the I&O Forrester Leadership Board (FLB) meeting, and I was the sole applications guy in the room - a conduit for I&O FLB members to vent their frustration at their apps dev peers. For those who aren't aware, FLBs are communities of like-minded folks in the same role who meet several times a year to network, share their experiences, guide research, and address the issues that affect their role.
We infused the session with equal parts education, calls for joint strategic planning across all IT work, and a bit of stand-up comedy - Glenn noted that as representatives of our respective roles, he and I were actually twin sons of different mothers. I noted that in that context that our parents must have been really ugly. Once we opened the session for discussion, the good folks in the room wasted no time in launching verbal stones my way. Now, I'm no IT neophyte: I've been in the industry since 1982, and I'm no stranger to conflict - I grew up with 3 older brothers, and we all exchanged our fair share of abuse as siblings will. Still, I wasn't quite prepared for the venting that followed. To summarize a few of the main points, I&O sees apps folks as:
A few days ago, CSC announced its new Celeriti banking platform, which consists of five products: Celeriti Customer, Celeriti Deposits, Celeriti Loans, Celeriti Cards, and Celeriti Merchant. The solution includes, for example, a strong business process focus, business intelligence, and the so-called Web Portal User Interface. The platform has been built around IBM application infrastructure, runs on multiple operating systems such as z/OS, z/Linux, Linux, and Windows, and has been validated for use with the IBM Banking Industry framework. Here is my initial reaction to Celeriti.
I recently asked my Twitter followers if they had good examples of queries, business questions that SQL can't do. It turns out a better question is "what SQL can't do easily", so I thought I'd share with everyone what I heard and found. Seth Grimes was the first one to provide an excellent answer with some informative examples - thank you, Seth! I also found very useful articles on typical SQL challenges such as avoiding multiple duplicate sets in your SQL results, and why NULLs create tons of headaches for SQL coders.
There's also a typical SQL challenge with ragged, sparse, unbalanced hierarchies and dimensions. For example, a retail store, a wholesaler or a distributor with thousands of products, and a manufacturer with thousands of parts often struggle with dissimilar data. A pencil in an office supply store does not have the same descriptive attributes (lead type, for example) as a calculator (scientific, financial, etc.) or an office chair (number of wheels, etc.). Or a tire in a car manufacturing supply chain does not have any common descriptive elements (rubber grade, width-to-height ratio) with gear boxes (automatic vs. manual, 4 or 5 speed, gear-to-gear ratios, etc). When looking for correlation between two entities (for example, what is a potential product quality issue that is making my sales go down?) in cases with disparate, dissimilar products (as in retail products or manufacturing parts), the same SQL query cannot work for all products or parts. One would be forced to write multiple SQL queries for each product or part type to find such a sales/quality relationship.
Some days ago at Forrester’s IT Forum in Lisbon (June 9-11) I gave a presentation together with my colleague Andy Bartels on the IT market recovery (we predict a 9.3% IT market growth in 2010) after two economically challenging years in 2008/9. In fact, we were making the point that the market rebound we currently see is not simply a recovery but the beginning of a new IT hyper growth phase fueled by a new wave of innovation.
A strong driver of this innovation is what we call Smart Computing at Forrester: the integration of physical world information into intelligent IT-supported business processes in 4 steps: Awareness (via new sensor technology), Analysis (with advanced BI solutions), Alternatives (including rules and process engines) and Action (in industry business applications), plus a 5th feedback loop of Auditability for tracking and learning.
A well-known example of smart computing solutions is smart metering in the Utilities industry. In another presentation in Lisbon, a colleague asked the audience, a room full with all the leading IT service companies, who all had an initiative running with smart metering – everyone in the room raised their hands. Then he asked who actually had more than 1-3 (pilot) projects running – and almost no one raised their hand.
Is smart metering just hype that everyone is jumping on or what is the reality of the lighthouse example of smart computing at this point in time?
Java's future is on my mind lately. Oracle's new ownership of Java prompts a series of "what will Larry do" questions. But more to the point, the research Mike Gualtieri and I have been doing on massively scaled systems makes me worry that Java technology has fallen behind the times.
This is not a "Java is dead" commentary but rather a discussion of issues as I see them. Java technology is alive and vitally important; we all must be concerned if its future direction isn't clear.
For me, Java's 2-gigabyte-per-JVM memory limitation symbolizes this gap. Volumes of application data are rising, but standard Java platforms still have a practical limitation of 2 GB of memory. I spoke with one customer that incorporates a search process into its app that alone requires 20 GB of memory. This customer employs servers with 6 GB of memory each but can only use this memory in 2 GB chunks, each chunk managed by a JVM in a scale-out architecture.
We've done pretty well with 2 GB JVMs until now. But as data volumes grow, this company (and others) are no longer well served by scale-out JVM architectures. Java technology should give shops the choice of scaling up the memory within an individual JVM as well. Why?
In discussions on cloud computing, I often talk to architects who have been told to create a "cloud strategy." This sounds appropriate enough, but there’s a devil in the details: When the task is "create a Technology X strategy," people often center strategy on the technology. With cloud, they aim to get a good definition of pure cloud and then find places where it makes sense to use it. The result is a technology strategy silo where cloud is placed at the center and usage scenarios are arranged around it. The problem with this is three-fold:
Considering the full business dynamics of any given usage scenario, there is a wide continuum of often strongly competing alternatives to pure cloud (including cloud-like and traditional options).
The rapid pace of market development means that business value equations along this continuum of options will keep changing.
Your business needs integrated strategy for many technologies, not simply a siloed cloud strategy.
Oracle Siebel CRM and SAP CRM still offer the most complete solutions, with improved usability. SAP has been steadily working to fill out its CRM offering, resulting in end-to-end process integration support that no longer comes at the expense of missing CRM functionality. Meanwhile, Oracle Siebel CRM is still the most full-featured CRM solution, with a breadth and depth of functionality for many industry verticals. Both vendors have moved to address key complaints: poor usability, high cost, and long implementation times. Siebel 8.1 features the Siebel User Interface, which can be highly personalized and is task-driven. The SAP CRM 7.0 UI is flexible to support varying roles and offers drag-and-drop personalization that allows any section of any page to be rearranged by the end user. Both vendors are working to lower total cost of ownership (TCO) for their customers by introducing more preintegrations with other solutions from within their respective corporate families and offering “rapid implementation” methodologies and tools to reduce upgrade costs.