Monday, April 6, 2015

Installing Oracle 32 ODBC Drivers from the 12c Client

When you install the 32 bit Oracle 12c client on a Windows 64 bit server, the ODBC drivers don't show up.  You actually have to run the following from the command line:

%windir%\SysWOW64\odbcad32.exe

Once you run it, the ODBC drivers work fine.

Thursday, September 25, 2014

Windows 8.1 and the Cisco VPN Client

Cisco stopped updating their VPN client a long time ago but there are many of us that continue to use it.  Mostly because we're required to.  I recently updated my home laptop to Windows 8.1 and my VPN client stopped working.  I tried uninstalling and reinstalling multiple times but that didn't help at all.  I did quite a few internet searches as well and was getting nowhere.  Finally, I found a forum entry that solved the issue for me.  It has to do with DNE (which I don't know what it stands for but it has to do with low level network functionality and is used with VPN clients).  Here's how it worked:

  1. I uninstalled my Cisco VPN client.
  2. I went to the site:  http://www.citrix.com/go/lp/dne.html (I thought it amusing that I'm using a Citrix solution to a Cisco problem)
  3. I downloaded and ran the winfix.exe program (ftp://files.citrix.com/winfix.exe)
  4. I rebooted my computer.
  5. I downloaded and installed the latest DNE (ftp://files.citrix.com/dneupdate64.msi)
  6. I reinstalled the Cisco VPN client.
That fixed my issue and I am now able to VPN in to work.

Wednesday, June 5, 2013

SOA - What and Why

Service Oriented Architecture (SOA) is more of a mindset than a product.  In fact there are many different products you could use for SOA and you could also use none.  It depends on how you implement it.  In other words, it is a philosophy more than it is a product.  Yes, there are many products that follow the philosophy but having a product doesn't make SOA successful as much as following the philosophy does.
 
SOA, as I think of it, is about standardizing and managing your integrations.  The goal is to create an accounting of what you have, eliminate tribal knowledge (you know, the stuff that only this one techy guy knows), and simply integration management.  It's the idea that data flow from one application to another, be it legacy application or cloud application or something else, should be done in a standards-based way, a way that is not dependent on a particular application or vendor.  My most common example is web services. 
 
Web services are based on standards, the are created and maintained in a consistent manner, and they developed/administered outside of the source and target applications.  So now you can have a single team responsible for integration instead of one resource here and another over there, etc.  It also means that if resource A leaves, resource B can pick up where A left off and not have to try to figure out what and how A got these two things to talk to each other.  That's one benefit of SOA, the reduction or even elimination of tribal knowledge.
 
Unfortunately, web services is not going to be supported by every single application.  That's why there's enterprise service buses (ESBs).  These work like translation layers.  They talk to legacy applications in a way they understand and convert that data into your integration standard (like web services).  On top of that, they are a tool for monitoring your integrations as well and catching issues before they become problems. 
 
Another aspect of SOA is governance or change management.  Ever had an application break because something it depended on changed?  You know the stress of trying to find out what broke and why it broke while people are freaking out because some widget is down?  Effective SOA governance can eliminate almost all of that.  Yes it's a pain to track down and effectively document all of your applications and integrations.  Yes it's a cultural shift (and not necessarily a popular one) to record any new or changed integrations.  But, once in place, good governance can take care of many problems before they become problems.
 
So, that's my take on SOA in a nutshell: standards-based integration and good integration governance.

Monday, June 3, 2013

The User Experience

It used to be that users would just put up with what they were given.  If it a was a long, complex process or a non-intuitive application, they would just do it because that's all there was.  Times are changing.  There is a lot more competition and a lot more options and if your customers don't like you, they can find someone else.  This is even true in higher education.  Students transfer all the time or drop out or whatever.  They are not a captive audience and should not be taken for granted.  Fortunately, they are not and many colleges and universities are increasingly trying to make their students' experiences better.

A huge part of the student experience is the administrative overhead.  Getting accepted, registering, enrolling in classes, getting financial aid, etc.  While modern technology has made all of this possible over the web, it is usually provided by different systems of varying age.  The could make applying an entirely different experience from registering which could be entirely different than financial aid and on and on.  This creates headaches for student and even for staff as the students are then calling and/or visiting various departments for help.  What is needed is an intuitive, consistent user experience.

Creating a good user experience is no simple task.  There are technical, design, and political challenges that will have to be overcome in order to be successful.  It's a long and sometimes expensive road but, in the end, you have the opportunity to build something that makes things easier for the student, for the support staff, and may even save money and time in the long run.  It's really a win win situation.

So how do you do it?  First of all, you can't just buy some content creation tools and walk away.  You can't even buy a whole portal suite and walk away.  If you want to be successful, you must link the IT back end with the user interface front end in a way that will serve both.  So, if your organization is like mine, you've got a mixture of legacy enterprise applications mixed in with a few cloud applications and held together with duct tape and baling wire.  How do you link all of the data and processes you need from these applications?  The answer is SOA.

The whole point of a service oriented architecture (SOA) is to organize and integrate your applications in a way that is standard and flexible.  The simplest way is to standardize your integration as much as possible (using web services or something similar) and use an enterprise service bus or something similar to translate the data from incompatible applications.  Basically, you create a standard set of web services that not only integrates your current applications but creates a standard way for the new user interface to interact with all of your applications.  It lets you create a single interface that spans multiple systems.  Yes, I realize that my simple paragraph here is quite possibly several years of work to implement.  It's never as easy as it sounds.

Once you have your SOA layer, you can provide your user experience development team with the tools they need to develop and maintain the user experience.  Gartner calls this the User eXperience Platform (UXP).  The goal of the platform is to provide the tools to create a great user experience on the desktop, tablet, and smartphone.  As a platform, this is an new/immature concept, but there are all sorts of tools popping up that fill some or all of the requirements.

The last thing to remember is that the UXP must be agile.  It must be able to change and change quickly to the needs of the user.  Building the infrastructure and finding the correct tools is a huge and time-consuming task but the updates and process re-writes, etc. should not be.  Adapting to new technologies should not be.  Adding and removing back-end applications should not be disruptive.  This is the purpose of the SOA layer, to make sure the data is accessible in a standard way that reflects not only today's needs but tomorrow's as well.

Thursday, May 30, 2013

Choose you this day...Enterprise

In my previous post, I outlined the three primary consumer ecosystems and their differences.  Now let's talk about the enterprise.  There is a lot of the same thing going on but with an interesting twist.  First of all, if I were to name the top 3 enterprise ecosystems, I would have to go with Microsoft, Oracle, and SAP.  There are other best of breed and open source, etc. but I think these three are the really big ones.  Unlike the consumer space, the enterprise space seems to only have one business model for vendors, sell as many licenses of as many products as possible and make it difficult to change vendors.

All three vendors have tight integration among their products.  All three have great value propositions.  And all three want you to buy as much from them as possible.  In other words, they want to be your single source - for you to be a Microsoft shop or an Oracle shop or an SAP shop.  Their applications are feature rich but complex and can be very difficult to manage.  They are all customizable (to a point) but become more difficult to maintain the more customized they are.  They all can make the claim that it's easier to standardize on their ecosystem than to try to get best of breed systems.

For a long time that was the way it was.  You picked what best suited your needs and you stayed with it (because moving was way to expensive and time consuming).  However, there's a newcomer to the crowd, cloud systems.

When service oriented architecture started gaining steam, enterprises began to use web services and other standards to integrate their systems.  They found it not only made integration easier but it made their systems modular and more easily replaceable.  If the same feeds that provide data to and from PeopleSoft, for example, can provide data to and from Workday, then these huge on-premise systems could be replaced with cloud based systems.  Further, if these applications (HRMS, Financials, etc.) are not critical differentiators for the business, is an onsite application worth the time and resources to build, secure, and maintain it?  As cloud applications mature and become more and more pervasive, will the huge, complex, onsite installations start to die out?

It seems odd that at a time when consumer ecosystems are becoming more and more closed, that enterprise systems are actually becoming more and more open.  While consumers are getting more and more locked in, the lock-in strategies of enterprise vendors is starting to fail.