Archive Group III : Navigating the Corporate Muck

In the beginning

2/28/2008 11:04:22 AM

The difficult we do immediately; the impossible takes a little longer.

- Moore's Law and the US Navy Seabees' motto

So you’ve decided that Oracle Application Express is a really good fit for your company to build and configure web applications for internal and external use. Then you get that sinking feeling, how do you convince the company it is as good of an idea as you perceive it to be.

First, you are probably an analyst at my level that is trying to keep your fingers in the dam of end users building complicated Access databases, spreadsheets or some other desktop app that suffers from weaknesses in security, compatibility and flexibility that you or your group will ultimately have to provide assistance and support on.

For the record, I do not disapprove of end user development of workgroup applications. In fact, I am a proponent of the idea that who better knows their requirement then the user or someone that is involved in the process.  I usually recommend having a sandbox enviornment for them to work with or installing the Oracle XE product locally to give them free reign to move and grow with it. OXE also allows you as the IS Professional to migrate to a server with lower chance of compatability issues. (Call it Win-Win)

So now, much like Sisyphus, you are faced with the daunting task of moving this idea up the hill of corporate politics and policies. Take heart, you are NOT alone. Like any idea or technology, if it is new to a group of people there will be a short list of reactions.

1. I LOVE IT , GIVE ME MORE
2. Why change what isn’t broken.
3. Whatever
4. No

My next entry will take each of these in closer detail on the ins and outs of these people and how to mitigate the adverse and capitalize on the best parts to move you forward.

Comments (none)

Grab your rock and get to work!

3/3/2008 11:59:13 AM

Continued from 2/28/2008 : "In the Beginning"

  No matter what you are introducing to an organization it always has a common trait.  It's new.  New things always run the same gambit with people that the thing is introduced to.  As I said before you will get a short list of reactions to change and it is all about what you as the holder of your particular boulder, reference (Sisyphus), do with those reactions that can determine if you make it to the top of the hill or not.  

  The key here is to have a strategy of introduction that improves your chance of success.  It has been my experience that the lower-level analysts of an organization have a better understanding of the how and why of new techniques and tools than the upper mamangement. (I think I saw a Mathematical proof to that effect some time ago too :") ) Given that, is is reasonable to assume that these analysts and managers that are in or close to the Trenches have some good, creative ideas to get things moving more smoothly.  Then why is it that the vast majority of technology choices are often made from the top down rather than the bottom up.

  The truth is that you have any number of ways that something like APEX can become widely used in any company.  The first, and most obvious, way is to run the gambit of policy and politics through the chain to discover that red tape exists in abundance in even the most empowered of organizations, it takes time, effort and emotion in spades to make this path work, moch more to speed the process along.  The second option is to proof, collaborate and communicate then divide and conquer.  The people are your key. 

  The Early Adopter

  These people are great!  They usually are very enthusiastic about the 'thing' you are bringing to them and can help to get momentum to your efforts early in the game to win over the hearts and minds of the next groups of people.  The early adopter is like an Evangelist in the way they spread the word about what it is and how (or how well) it works for them or their customers.  In many ways you are one of them, quite possibly the first.  When you get this kind of person on board the net effect is that the momentum of your effort increases and becomes more self-sustaining.

  While the impact of an early adopter is often some of the most positive influences there are dangers.  Becoming an Early Adopter means investing energy and emotion into the effort.  It also means that the these people have 'needs'.  They need soulutions that solve their problems.  By the way getting an early adopter means that you may have built them something to either impress them on the technology or fulfilled a business need they had , or both.  The key here is that taking the shorter path of public oppinion for a new technology makes it more of a barter economy.  Just make sure you know when to say when on how much you are putting into that economy as well.

  The benefit of the early adopter is the access to the minds of our next group of people.  They are the ones that have solutions, possibly aging ones, that are comfortable with the groove they are in and may need some convincing to move in another direction.  BTW these are usually the ones that when something new is forced o them they can become more resistent to that change for the sake of it.  The overview point here is handle with care. 

To be Continued.................... 

Comments (none)

Moore's Law or Murphy's Law, take your pick

3/6/2008 4:35:30 PM

Continued from Grab your rock and get to work! on 3/3/2008

  I am often suprised at the amount of time I hear the phrase "If is isn't Broken, why fix it?"  Now if it were up to me, I would personally watch the effects of Murphy's Law take place and wait for them to come back and confirm that it broke.  However, like so many, my job is to evaluate and determine the best possible solution going forward, and be proactive about it.  Believe me you really don't want to know what life is like having to maintain an old VMS system using printed manuals and an E-Bay account. (not Pretty)

  The fact is that the very nature of technology is that it progresses.  As we progress we get newer, shiney, toys.  What many people who resist change for the sake of it don't realize is that many of the older technologies very quickly are superceded and fall into decreased support and then to obscurity.  So change is more of a requirement than an initiative.  The question becomes how to convince this type of person that the proposal is a good risk to go forward?

  The first thing to keep in mind is that these people are comfortable and secure in their environment.  Change does not generally come easy unless they are seeing the pain of the process they are in.  Even then you might come up on someone who is comfortable regardless of the pain.  Sometimes the best way to mitigate these personalities is to do show and tell.  Show them some good, small, examples of how the proposal fits their needs.  Keep an ear out for those good key topics where they might be uncomfortable with their situation.   Then find ways to make it work for them.  The benefits to having these people on board is thet they make you understand more about the business and the concerns of many users in their jobs.  As momentum builds these users will likely get swept up in the effort but the first few will help you to flush out all of your arguements for the harder sells of the effort.  Unlike the Early Adopter, you'll have more work to do but it is ultimately more worth the effort. 

Comments (none)

'Resistance is ...' Trademarked!

4/29/2008 3:07:24 PM

Continued from Moore's Law or Murphy's Law, take your pick on 3/6/2008

How much fun can one truly have when Navigating the Corporate Muck.  Well, friends, if the previous posts on this line of thought have not been enough to scare you away then I have yet another group of people for you to convince to see you point and accept the fact that change is, indeed, a requirement of life in the wonderful world of business and technology. 

This type of person, while small in number, have a huge voice that they are never afraid to use.  The resistence to change is so strong that they seem to be fighting the battle of their lives over a noble cause.  Not really, they are just more comfortable in their position than any other. 

So how do we deal with them, get them on our side and remove the resistor to the process of change?  Truth is that in many cases you won't.  The best that can be hoped for is to find either a passive-resistant medium where they do not feel it is an obligation to interfere or to build up so much momentum in previous acceptance that they find themselves overwhelmed by the tide and follow the group, albeit grumpily. 

You would think that I might suggest to you that these are the first or second group to be assimilated in an effort to get APEX or any new tech in the door, but no.  The reason I suggest that you handle them last is that, while small in number, their raised voices can turn the tide on the late adopters and make the job of gaining acceptance that much harder.  It is a bit of social engineering but the later in the game these people are allowed to yell about how they don't like change the better.  It saves the effort and keeps your stress level from spiking high enough where you feel that it isn't worth the effort.  Have faith, by the time the just-because resistence comes to bear, if you have laid a proper foundation for your effort, it will only be token resistence.

So in Summary,

1.  THINK!

2.  Find your early adopters and 'help' them become advocates

3.  Plan to show more than you are asked when it comes to winning the fence-sitters

4.  Don't try to win your 'just-because' resisters, too early, unless you have no other choice.

5.  Relax, this is an iterative process and it is not worth popping a vein over. 

6.  Finally: "Smile, it makes them wonder what you're up to." - SJG "Wisdom of the Illuminati" 

Cheers everyone!

Jason

Comments

- 4/29/2008 5:42:38 PM

Hi Jason,

  I came to this blog thru your post in the APEX blog about the SOX requirement thread. I know exactly what you mean. I am kind of going through the process of resistance (eventhough it is the right thing to do) for a similar kind of project in Oracle, so, I will try to follow your points. They make so much sense.

Thank you,

Rahul

 

RPRT Theory (Right Place, Right Time)

4/21/2009 5:05:41 PM

Have you ever had one of those moments where you felt like you showed up at the right place, at the right time?  I know we all tend to have more mixed results of the reverse, but it these time where you have to really think about how did that moment in time come up?  By design, chance, fate, or just dumb luck. 

In a lot of cases previous discussions have been geared toward shaping the destiny of a project through stakeholder analysis, or manipulation. However, recently I had an encounter of the truly rare kind in business technology, where the conversation starts friendly and progresses in a direction that is unexpected, almost eerily so.  A close friend of mine, stopped by my place recently just to say hi and chat a bit.  After a few minutes, he noticed some papers on my table, it was an ERD of all things.  Then he asks me a fateful question, "Do you know about Oracle Databases?"  First off my friend is a business guys that knew I am an 'IT Guy' but not specifically my skills.  I told him yes and the conversation took a direction toward his project's efforts and failings with getting an IT group to help them build a pilot environment for a new application they were looking to bring in.  When I asked what the issue was he tells me that they assume that the resources in time, equipment, and money would make it out of the question.  So they declined to even evaluate the pilot request without a full work-up (Business Case, Requirements, Resource Estimates, and all).  My first inclination was that they must've been buying the wrong product to have that kind of response.  When he got into telling me the actual stuff they needed my jaw hit the floor.  Simply put, they needed an Oracle Database, an Apache HTTP Server, and as he put it 'some other product they call Apex'. (pronouncing it "A-pex")

In the last three years I have been advocating, outright Evangelizing at times, the use of APEX in this environment.  And just when I thought that I must've found just about every stakeholder that could keep it going, another one comes out of the area that I least expected them to come from, not realizing that it was here.

To keep a very long story short, I was able to produce an environment for this project immediately, where they had assumed one didn't exist.  The pilot project is now more than a month ahead of schedule and all it took was having a mess of paper in my space and a chance encounter with a friend that asked the right questions at the right time.

It just goes to show that where there is one there might be more so I need to grab my rock once again and get to work.

Cheers everybody!!!!! 

Comments (none)

while :new.apex = :old.discussions loop (Loop : 1)

7/20/2010 3:23:14 PM

Welcome Version 4.0

Oracle Application Express (APEX) 4.0 arrived this month with anticipation and fanfare equivalent to a really large family reporting on a new grandchild being born. Having had a bit of time to explore and experiment with the new version I am more than impressed with this new and large step forward in the product. After a few weeks of beating up these new enhancements it has become clear that this software is going to be a force to be reckoned with for some time to come.

This latest release has brought some old conversations back to the surface in the many political, social, and techno-theological aspects of the business and IT organization that employs this software. (or finds that it is being employed ;”)

To RAD or not to RAD

Rapid Application Development (RAD) has been a subject of contention in the business realm for a few years now. It’s not to say that RAD is bad; just that it takes a certain understanding that it can and will get messy, if it is not controlled properly. Not all, in fact most, organizations should not use this methodology of software development because of this fact. (insert ‘popular OS’ joke here)

As a result of personal or organizational experience with RAD, many IT Architects shun any tool from the IT portfolio that has been remotely associated with RAD. The issue here is that RAD is a methodology not a programming toolset. One can, conceivably, use RAD with .NET and JAVA to create the same mess that they can get into with any other application development toolset available.

APEX has fallen prey to this misconception before and likely will again until some of the detractors actually sit down with it and understand that normal, organized, documented, and controlled application development can be done with it to produce functional, secure, scalable, and stable applications with it. APEX is not RAD but it is Radical in that it allows a team to use their own methodologies in the creation of a business application. In my experience APEX has the overwhelming advantage of producing the application quicker than the other options available.

Be it RUP, SDLC, RAD, Agile, or any other methodology, a toolset has to be used to create the application, but that toolset is not the methodology and likewise.

Comments (none)

while :new.apex = :old.discussions loop (Loop : 2)

7/20/2010 5:46:24 PM

Objectivity is in the Eye of the Beholder

Everything one encounters in life is subjective to our particular point of view. Be it social, political, theological, or theoretical; all people tend to see things different from others. Likewise, organizations of people tend to operate under the same dictionary as others with slightly to more different definitions. Take the term ‘Enterprise’, for instance.

When thinking of the idea of Enterprise software or software development most people might assume that the application would be produced using some really complicated development tools like .NET or JAVA. At the time when I encountered Application Express (HTML-DB at the time) I was thinking roughly the same thing. A few years later Oracle published a slide deck that show many things, but the one slide that catches the most attention when I show it is this one : (Slide 11)

This graphic seemed to capture what many developers, including myself, had been saying for a while. APEX is a development platform that is accessible to all levels of business application development. With one exception that many of us felt very strongly that APEX deserved to be shown as penetrating further into the Enterprise development portion of the business.

APEX can run with the big kids, too

Why, or better, why not? I hadn’t truly gotten it until I had a conversation with a few members of the development team a few months ago. The reason for this disparity seems to exist in the difference in dictionary between what is called Enterprise Software Development and what many businesses call Enterprise Systems.

Depending on your definition APEX is, or is capable of producing, an Enterprise system. Many companies I have encountered express this as an application or series of related applications that service multiple business units and/or multiple business locations or sites. Being that it is a multi-target application development toolset APEX fits this definition very well in both the development tools and the applications it can produce.

Where it comes to Enterprise Software Development, I have heard, APEX doesn’t fit the bill entirely. Since this methodology apparently requires multiple developers to be working on multiple units of the whole system in order to complete the final product, with source control and documentation. In the previous post I spoke about methodologies and the fact that given the right amount of control any development toolset can succeed or fail equally. Either way, the newer enhancements to APEX seem to suggest that it fits this definition more today than it did even six months ago.

There is but one other definition of Enterprise that comes to mind and it is a really poignant one. It is that large companies, the ones that Enterprise Software is usually targeted toward, are rarely enterprising anymore. They don’t take the risks that make up this definition. They have resources that make buying a Commercial (“Enterprise”) Solution for everything possible and therefore they are more stagnant, less flexible and less open to change. This is a very good spot to be for the APEX platform. It sports the power and security of an Oracle Database. As a multi-target solution it can produce a suite of business applications for the business that can fit just about every conceivable need and can be supported by a minimum of personnel. It enables the organization that employs it to concentrate resources into common effort that can free up other resources to work forwarding the business rather than supporting excessively diverse IT systems.  While doing so with a lower cost of ownership than other tools.

In the end, I find that APEX fits my definition of being suitable and scalable to any Enterprise. Other opinions may vary.

Cheers! :”)

Comments