The Mobile Enterprise

The market place has been heating up with more powerful mobile devices that offer a broad spectrum of uses that extend beyond a personal device. The lines between a device for work and pleasure are becoming increasingly blurred and companies are adopting more uses for mobile devices in the Enterprise. With this trend comes increased complexity of how to extend traditional enterprise applications on these devices to increase users mobility, improve field services and drive new business efforts.

Recently I have collaborated with one of our Principle Application Architects to provide a high level review of this challenge using 2 of the top products inthe market today; Oracle Lite and MobiLink. Below is the summary review of the 2 products and how they stacked up as a platform for extending applications into the mobile enterprise.

Oracle Lite versus MobiLink
As the mobility market is increasing in popularity more companies are recognizing the value of pushing the current boundaries of enterprise applications to extend the reach into mobile computing. With the extension of the enterprise to mobile devices the strategy and technology used to support them has met the growing demand but offered some interesting new challenges along the way. There are many products on the market today that can be used for deploying mobile applications. I have been asked recently to compare two such products and offer a perspective. The two products evaluated which also happen to be leaders in this space; Oracle Lite and Sybase’s MobiLink. First let’s look at some of the core elements that are required of these products to baseline the evaluation approach.

In comparing these products there were a couple of features that did seem to be product specific. Some things that Oracle Lite has that enhanced the synchronization solution are:
Device Manager for application updates and patches for each client – Need value statement here. Why is this important
Webtogo and OC4J for web based and J2EE applications. – Same as above why is this important

One distinct difference between these two pieces software is MobiLink is session-based replication vs. Oracle Lite uses asynchronous replication. Both of these have their advantages and disadvantages.

Oracle Lite Advantages:
Incremental downloads are fast because the data has been composed on the consolidation database.

MobiLink Advantages:
Consolidation is performed when the user performs synchronization.

Need to list advantages as well since it is stated above

Environment Baseline
In order to create an environment to equally test the two products I have set up a small application syncing 16 tables for both Oracle Lite and MobiLink. The database assumption will replicate the solution to an Oracle database as this appears to be a fairly common type of configuration in my encounters., To keep the anaylsis straight forward the key attributes that will be measured are:
Performance
Development
Maintenance
Troubleshooting

MobiLink Publication
To get a feel for the MobiLink product, I created a small synchronization model synchronizing 16 tables. These tables ranged from having a few records to one table syncing 140,000+ records. The development environment for an experienced SQL developer is pretty easy to follow. You can customize various events in the synchronization process to suit your needs. Once you have set up all your business rules and synchronization package, you deploy your model and the software creates scripts for the MobiLink server, a client database (distributed using batch files), and the SQL for your consolidated database.

Oracle Lite Publication
I also created an application in Oracle Lite using same tables as MobiLink to get a good baseline for performance and used the Mobile Workbench for development. If you have read my blog, you know that I use the Java APIs for development and the reason that I have chosen this path is that the APIs give me something that I can quickly reuse on any Mobile Server environment along with added flexibility in deployment options. With the Workbench, you first create the publication, then you create the publication items, you add your publication items to the publication, and finally you deploy your publication.

Results:

Performance
I had an assumption that Oracle Lite would be faster for synchronization performance, the only thing that I thought might be quicker in favour of MobiLink was the fact that it synched via TCP/IP. The test was to do an initial synchronization of 16 tables. MobiLink remote databases are already installed on the client, so they have a head start. But even with that head start, Oracle Lite was much faster then MobiLink. Oracle Lite synchronized 157,131 records in 13 seconds. The same amount of data took MobiLink 1 minute and 38 seconds.

The most common challenge for most new users of Oracle Lite is the sizing and background performance of Message Generator Processor (MGP). Sizing of the enterprise database for Oracle Lite accordingly, most people run into issues with space and IO waits. This is probably the most common factor that user run into with Oracle Lite. Typically back to my assumption replicated to an Oracle database. If you have Oracle DBAs already on staff, those skills can be leveraged to assist in the Oracle Lite optimization.

Development
Mobilink offers an advantage to very novice users and appears to have the better development environment. This is due to the fact that all the customization can be performed with modification to some simple SQL scripts. Based on your skill sets and strategy this might be an approach however it has some drawbacks. The most significant one is you have to go through these scripts to update various events with your new customized SQL each time and update or deployment is required. This might be ok for very small (30 – 40 tables) environments, but in true enterprise environments this could become more difficult exponentially.

Oracle offers a different approach to this same type of synchronization event. They achieve this in a similar manner by allowing you to adjust the Sql neede for replication but they build the deployment packages for you. These packages can be tailored or customized if necessary but in my experience it has not been neccasary. The one benefit I did find with Oracle Lite is using the API’s for advanced tasks. The API’s allowed me to create integration scripts that could be reused and ended up making the deployments much easier to manage.

Schema Evolution
Schema evolution is the changes that happen to a database during the life cycle of the application. Tables can be added, modified or deleted during the life of an application. Schema evolution is usually a significant challenge for most mobile systems because getting a schema changes to the client without disrupting the users is extremely difficult.

Oracle Lite holds a clear advantage in schema evolution. In Oracle Lite, to make changes to a table in you application:
1. Stop Mobile Server.
2. Change the Oracle database schema (add/drop column).3. Create a Java program to call the ConsolidatorManager API AlterPublicationItem().4. Start Mobile Server 5. Execute sync from the client 6. The change to the table will now be available on the client.

Typically you should not have to stop/start the server, you can just reset the metadata cache, but it is good practice to shut down the server so no one tries a sync while you are performing the change.

For MobiLink schema evolution, I am going to send you to Dr. Dobbs Portal. Apparently to achieve the same function you have to build something that will do this and it does not appear to be as easy in the long term as Oracle Lite.

Along with schema evolution, comes referential integrity. How does MobiLink handle this? Once again I will send you to Dr. Dobbs Portal. Oracle Lite uses table weights. It applies change to the tables in the order that the publication items are assigned a weight. So, all the number 1 items get applied first and the number 2 items are second, and so on. Three methods for applying weights are manually determining your FK constraints per publication item, use the API method assignWeights(), and finally, you can run the code that I have in this post to determine your weights.

Troubleshooting and Debugging
The better your resources are for troubleshooting issues, the less time it takes to resolve issues. I haven’t worked with the MobiLink product enough to identify how good the tools are for troubleshooting. I can however comment on Oracle Lite’s troubleshooting resources. Since I have started working with the product, I would have to say Oracle Lite’s documentation is probably the biggest improvement Oracle has made to the product. Starting with the 10g R1 release, Oracle has added tracing to the following:
GLOBAL
SYNC
MGP
MGPAPPLY
MGPCOMPOSE

In those 5 areas of the synchronization life cycle, I can set debugging to 6 different levels (mandatory, warning, normal, info, config, finest, and all). From that, I can select 6 categories as well (general, SQL, timing, data, resume, function, and all). Then finally, I can set this for all users or I can simply specify a list of users. I can do this on the fly through Mobile Manager and gathering the results I can quickly resolve the issue combined with the schema evolution, fixes have hardly any impact to the user base.

Oracle Lite has also added debugging to the client and SQL tracing of all SQL statements that are executed on the client. For the client, this is as simple as changing this variable in the polite.ini to OLITE_SQL_TRACE=YES. With the Device Manager, I can specify that I want to add some debug information for a particular user. I can then get the user to perform the action that is causing them grief, and with the Device Manager I can then pull the debug file from their device.

Administration
MobiLinks doesn’t have a user administration interface. You have to create your own and hook it into their application. So, on top of developing all the code to do your synchronization, you are going to have to spend some time identifying ways to administer the users. Oracle Lite has the Mobile Manager. If you are familiar with Oracle OEM tools, this follows the same conventions. From Mobile Manager, you can monitor syncs, get debug logs, monitor MGP, add and remove users, add users to applications (did I mention one mobile server can have many publications). Training support staff for trouble shooting is easy with Mobile Manager.

The Mobile Manager can be deployed standalone or on top of Oracle Application Server. Oracle Lite is an n-tier based enterprise solution. If you require the use of the APIs to create your users, here is a sample:
MobileResourceManager rm = new MobileResourceManager(con);
rm.createUser("USERNAME", "PASSWORD", "DISPLAYED NAME", "U");
ConsolidatorManager cm = new ConsolidatorManager();
cm.openConnection(con);
cm.setSubscriptionParameter("PUBLICATION_NAME", "USERNAME", "BIND_VARIABLE", "'bind value'");
cm.instantiateSubscription("PUBLICATION_NAME", "USERNAME");

Conclusion
If you fall under the following category, then you should be choosing Oracle Lite as your mobile solution:
Already using Oracle Enterprise Database.
Already have an application using Oracle Enterprise Database that has a business requirement to go mobile.
Have a J2EE or .Net application that you need to port to a mobile environment.
Required synchronization of high volumes of data and high volume of tables and database objects.

Reasons to choose MobiLink are:
Your enterprise database is something other then Oracle.
Lots of resources on the net. Web casts and other information available.

Final thoughts
MobiLink seems to be a good product and fulfills many areas of mobile environment. However, MobiLink does not seem to have an enterprise approach to mobile computing.. The MobiLink product requires a fair amount of coding before you have users up and running. Oracle Lite seamlessly integrates with Oracle and Oracle Application Server giving you an n-tier enterprise solution for your business. Over time the current draw back of Oracle Lite such as lack of documentation will improve. The technology appears to be solid and is applying the lessons Oracle has learned in the Enterprise. Looking at the total cost of ownership it appears at a high level that Oracle Lite could have a distinct advantage of a lower cost over the life of a mobile enterprise application.

Enterprise Architects: Part II

Recently I have seen the discussion heating back up regarding the role of the Enterprise Architect. As most of us know at this point there is not right or wrong answer to the question. It is a matter of interpretation of the individual organization. There in itself is the challenge…

If you look at some of the fundamentals that started the EA focus such as the Zachman framework you will notice less of a technical focus in the beginning and more focus around the business aspects (processes, departmental interaction, financial forecasting and budgeting). As you know the ideals of the framework were to remove the unpredictability of IT systems and increase the integration at a business level so that organizations can derive the global impact of changes not only to the organization but to systems. It is this fundamental that allows IT to remain fluid and in alignment with the business.

Somewhere along the way it has evolved into using the title as a catch all to include systems architects, software architects, etc. From what I have experienced serving as an EA in the Federal and Commercial sectors it is still unclear for most what the position really does.

From my experiences I have had some degree of success with the following model:

The Enterprise Architect works with the CIO, CFO, and CEO to link the business strategy to the IT strategy and the current IT portfolio. From there he/she determines the roadmap to bridge the gaps and set the path for innovation if required. Typically this person will run a team of solution or application architects and business process architects (also referred to as analysts or engineers).

In this model the solution or application architects have the platform specific skills but the EA is versed well enough to make critical design decisions regarding the bigger picture to ensure technical integration as well as integration with the business.

Most people perceive Enterprise Architecture and the role of Enterprise Architects as a financially driven one rather than productivity based one. For this to truly be resolved in my mind it will take people like us to drive a consistent standard for the industry to adopt and follow. My two cents…

Outsourcing Data Centers

Here is an interesting article on considerations when looking at outsourcing data centers. Keep in mind that perspective is everything. There is always a gap between theory and application when approaching these types of efforts for an organization. There are some good recommendations in this article but when it comes to applying them there is some level of organizational evaluation that needs to be compeleted before considering some of the options. Anyone who has delivered large complex enterprise level systems knows to never under estimate organizational culture and people when evaluating some of the suggested changes.

I think the author(s) did a good job of exposing some of the things to consider when looking at this type of effort.

http://searchcio-midmarket.techtarget.com/tip/0,289483,sid183_gci1317450_tax311252,00.html

Good SaaS Report by Baseline Magazine

Well done survey of current SaaS customers and some good real world feedback as to the business model and its role within the Enterprise.

http://www.baselinemag.com/c/a/Web-Services-and-SOA/Software-as-a-Service-Survey/

The Transforming Role of the Enterprise Architect

Along with Enterprise Architecture coming under increasing scrutiny the role of Enterprise Architects (EA) is having image problems as well. Most CXO’s understand at a high level the function of the role and may even value it but find it difficult to measure or quantify the value in business terms. At a macro level for all of us that challenge is the same.

In my experiences I have found that there are different ways people evolve into the role of an EA. Some come from business backgrounds and process engineering backgrounds or they have a technical background and have been a technical architect at some point in their career. The interesting thing about EA’s is that in my mind the industry has not really had a good definition of what an EA actually is and how they drive value.

To tie this together and provide a broader perspective we need to look at one of the current industry trends in the IT field today. The current trend of IT to business alignment has had resonance for some time now and people are beginning to understand how to bridge the chasm. There is alot of activity around IT to BT (business technology) mapping and how IT can better drive value back to the business function it is supporting. If you have an EA employed who is not driving this value than it is the right role but might be the wrong resource in that role. The role of the EA is usually not as clearly defined as the role of a developer of even CIO at time. It is usually left to the individual who is filling the EA position to define after they have filled the role.

So now that the problem has some more color how do we approach the role of an EA and how will it drive value in the end. The best way to start is as with all good beginnings, partner with your head of Human Resources (HR) and the business executives that will receive the benefit of what this role could bring. Taking this approach and gaining buy in from your peers goes a long way to help in the alignment process. If aligned correctly this role will drive the business to IT alignment and governance models ensuring the partnership remains healthy as the dynamics of the business climate change.

Some of the key attributes that a successful EA should have are typically:

a solid understanding of business models and how P&L works from a business leader perspective
technology agnostic in everyway and hopefully has served in a technical architect capacity
management skills to be able to work well with diverse blended teams

Having an Enterprise Architect on staff is not for the faint of heart for companies that are experiencing significant cost pressures. They are a senior level position that has more of a financial commitment than other positions within the IT function. Along with this having an EA approach to running your enterprise is a costly proposition. Adoption of this approach has typically occurred in the Federal sectors and larger Fortune 1000 enterprises where there is a little more discretionary budget to create the ability to focus on more strategic IT initiatives. This does not imply that this is an elite position reserved for a select few. I have witnessed and consulted with small to mid size organizations that have been successful in having EA’s that are multi-functional. Although this sometimes contradicts some of the primary disciplines of an EA, rules are sometimes meant to be broken. From what I can see that is what has driven innovation in our industry to date…

To have an Enterprise Architecture (EA) or not?

The topic of Enterprise Architecture (EA) has been coming under scrutiny in recent months as cost pressures continue to drive businesses to look for cost savings through driving efficiencies. If you have experience in large enterprises and have had to deal with the implementation of an EA than you know the complexity and cost of that effort. It is not only the creation of the architecture maps themselves but the staff, modeling tools, business and time commitments it takes to achieve the ROI that an EA is intended to bring. These all in costs can be staggering to an Executive who is really trying to achieve the fundamental goal of understanding the enterprise and how it drives value for the business.

In order to baseline this thought lets first understand that in my humble opinion the fundamentals of EA are good in their intent but are wrought with challenges in execution. Commitments from your business partners are typically very high, the software tools are expensive and the value of an EA diagram is difficult to qualify against the investment.

I believe that John Zachman's EA framework was a significant step forward for technologist who could not see that at the end of the day technology is great but only if it meets the business objective. It brought about a new way of thinking about technology and how to create solutions that drive to a business result measured in less binary terms. Now having been an Enterprise Architect in some very large enterprises both commercially and in the Federal Government I can see the value of an EA but offer a different approach to achieving the value as well as driving the savings through not only efficiencies but automation.

My approach leverages some of the converging technologies such as Business Process Management (BPM), Enterprise Service Bus (ESB) and Service Oriented Architecture (SOA). Instead of creating a diagram that is static and non-actionable I propose that EA's are input into a BPM tool and bring life to the Enterprise through the ESB and is governed by the organizations SOA strategy. This approach allows the technology the business to control the technology in a more transparent manner while increasing the value of the CIO/CTO, IT staff and existing IT investments. Leveraging automation, improved integration and the same business centric approach you can make systems more robust and adoptive to the changing business environment as well as improve agility of the component systems. It becomes easily updated as the business needs evolve and can audit the processes that run through the tools very easily.

Now with that said everything has to have balance. As a technologist it is critical to always have a business, not technology centric view of everything that we do in the new economy. The fundamentals of these approaches are to give us new tools to build from and new challenges to drive innovation. I believe that through this alignment IT can be more of a strategic business partner than in the classic terms that defined it in the past.

The Decompossion of SaaS

Software as a service (SaaS) has been creating a buzz for some time in all aspects of the IT industry. With all the differing delivery models, definitions, marketing messages and hype what is the value at the end of the day.

To understand the value it is my perspective that we need to look at how we got here. There is much debate on the history of SaaS and how it was derived. From what we have seen in our industry over the years, the Application Service Provider (ASP) industry paved the way for businesses to explore the concept of off premise software, accessed through the Internet or some sort of secure mechanism connecting their enterprise to their provider. Unfortunately the SaaS acronym is not new and was actually one of the original tag lines for a small company in Annapolis, MD. called USinternetworking who was one of the first pure play ASP providers. The concept has actually been around for about a decade now so what has changed?

Having grown up in the ASP / Outsourcing area of our industry the answer to that question is not complex; its the software that has changed. The move to web based technologies, applications migrating to web architectures and new deployment strategies made it easier than ever to support a SaaS model.

Years ago the strategy was to buy one software package that did it all and we saw the rise of Enterprise Resource Planning (ERP) applications. The strategy was solid in the theory that as a CIO I could standardize my processes, platforms and infrastructure to reduce inefficiencies, how bad could that be? What we found is that unless we truly partnered with the business, identified the right project charter or mission statement, the right business objectives and correct stakeholders these projects were sometimes not successful or ran over budget with ROI models that had diminishing returns.

Taking these high level factors into consideration brings the conversation to SaaS. Web based software, coupled with services and the value proposition is clear when it comes to ROI so what are the drawbacks?

Companies and organizations need to evaluate their application portfolios and contrast them against their security strategies and policies. This analysis will drive the SaaS or not to SaaS decision. Having corporate data off premise in a shared environment, which is how most of the SaaS providers are able to gain economies of scale, is a concern for some customers. Not having data on site, business continuity of the provider and some integration challenges need to be considered when looking at SaaS delivery models. In the end IT and all technologist have to remember it is about the business not technology, unless your business is technology.

SaaS has it's place as do all tools in the technology sector. Is it the end of packaged software? I think it may be to early to tell. In the end I think it is a good strategy for some and has a purpose. The companies that are currently providing software as a service have compelling business cases and drive value but we have to always remember in the big picture it is about the right tool for the job.