The Wide Grey Line

  Shadow IT is a Big, Hairy, Monster that will destroy our organizations if it goes unchecked.  Well, now that we have the drama and high emotion out of the way we can get something done.  First off, Shadow IT is a lot of things but it has been used as a rallying cry for many organizations to destroy it.  Why?  At first, I thought that maybe it was the cool name that made me think of secret agents, with pocket protectors, performing elicit acts of business terror and subversion.  How could any CIO allow any of their people to have such an awesome name as “Covert IT Specialist” or “Shadow IT Operative” when they were stuck with the second best of Chief Information Officer (CIO).

  That could be a clue.  The use of Officer in your title must mean that you are the moral authority and enforcer and therefore must remove these techno-criminals from the public view.  Now that I got that out of my system maybe I can be more ‘realistic’.

Shadow IT is the direct result of the mainstream thinking in the current theories of managing IT in the greater organization.  Today’s IT is all about rules, standards, structure, approval, planning, and execution.  I’m sorry with some of these terms it is hard not to lapse into the spy v spy comic book vision of “Shadow IT”.  Anyway, these structures and policies we claim to hold to in the IT business are mostly geared toward implementing big solutions, big value, and impressive functionality.   When we continue to indulge in the Big Picture of our statement of direction we lose a lot of focus on our primary mission as IT Professionals, namely Customer Service.

  The activities we label as Shadow IT comes from dedicating so many resources to big thinking that we forget that people have needs.  These needs are somewhat systematically being ignored or brushed aside as being non-value-added or too small to be subsumed by a by the Enterprise-class behemoths that we prize in business today.  When these needs go unmet the business customer begins a variable-length journey toward meeting their own needs.  There it is the seed is planted and the insurrection begins.  They find a book, light up their Office programs and discover that they can build the spreadsheet or database that will provide what they lack in actual IT support.

  In such a simple nugget you can see how many such drops in the bucket can add up to a biblical flood of data that your IT group neither controls, nor can support.  But you will eventually, because this scenario is played out daily as the seed grows and the complexity of the need exceeds what the person can do in Excel or Access.  They come to IT for help, only to be chided and turned away for this Shadow IT that we don’t support.  Then the next stage of the game starts.  The business unit see the value they have from their efforts and enlists (hires) a new worker that is a little out of place.  He has IT skills, yet is titled as “Admin Support Specialist”.  Better yet the business manages to find assets in the IT organization that are sympathetic to their cause and give unofficial support or guidance to them to make their lives easier or to earn good will in other areas.  Please welcome the covert IT specialist.

  This is the tipping point where our organizations begin to try to control or stamp out the Shadow IT and all it children.    But just like history shows us, attempts to eradicate desirable efforts, people or ideas just drive them underground, or into the shadows.  When efforts are made to disassemble or dismantle a good idea in the business and no effort is made to replace it with a viable alternative, you get just one thing.  Resistance.

So now we come to the ‘How do we solve it?’ question or expectation of the narrative.  Now, there are a number of really well thought out articles out there that can give advice on how to control, or defeat the hairy monster.  But many never tell you the truth that you can never fully win.  So now why don’t we embrace it?  Hell, expect and prepare for it.  The real truth is that the business customer knows what they need.  Not just their managers, the workers.  These people are very good at finding ways to fulfill their needs that is why we are talking about Shadow IT.

  What these people don’t know at first is that if solving some of these challenges with technology were as easy as all that we would not have IT.  We would not be needed.  The fact here is that we are needed but the big thinking is getting in the way of IT being focused on our customers’ needs and helping to solve them.  So, why not find a common ground. 

  If we found tools that could be more standardized, yet allow the business to create something for their needs.  What if we dedicated resources to work at this front?  Added an extra person here and there to our organizations to share the load and open time of our professionals to be that specialist and guide to these efforts.  Would that not be preferable to this perceived endless war of trying to pull the vile tree out by the root?

  My point in all of this is that the seeds of Shadow IT are planted every day and our effort might be better expended in growing ideas rather than trying to prevent them.  My challenge to the CIO at large is to decide to be there when the seed is planted and then decide to cultivate that new effort and shape it to the benefit of the organizations you serve.

Archive Group IV : Foundations of Application Development

Beginning Systems Analysis

5/8/2008 10:37:37 AM

  Blame my particular form thinking but I like to deal with business issues surrounding the IT industry.  By nature, when I see a problem or potential benefit area I look for ways to either solve the issue or to act on the opportunity.  Most times it is a good thing, others it just becomes 'Tilting at Windmills'.  It is fun and entertaining in any event.  (Keep in mind that my version of fun may not directly corrispond to yours, or the dictionary)

  With Application Express, XE, SQL Developer, and any number of other tools, our community has come to a point where the ability to attack a business need has definitly increased.  The APEX platform gives us a very concise and easy to learn Rapid Application Development environment to not only create an application but to quickly realize the benefits of that effort.  I came to APEX, html-db at the time, community when I saw that this was the type of system that could solve a lot more than just one or two issues.  I saw the potential to reap benefits that I previously would spend days and weeks just formulating the design for in other tools. 

  So since anyone in the community already knows this stuff why am I re-iterating it like a broken record?

  Without using any cliche, or attempting to do so, my observations of late have been that there is a whole lot of talented developers that can build just about any functionality into an application that one might desire.  There are books on how to do this.  I own more than a few of them now.  What is missing in all of this is the idea that systems development begins before you actually write code or build pages.  APEX lends itself very well to build first methods, but in this sense it becomes increasingly easy to build an application that is obscure, inflexible, and/or unsupportable.  This is the same with any tool you use and you can certainly do worse in most cases with other, hard-coded, systems.  Without some base thought processes and documentation, a new developer has a higher risk of losing their way or not being able to pull apart a broken component to analyze it and fix the issue.  Another fun result is that the progression of application developement is pretty predictable as the APEX platform evolves and as the individual developer increases in skill as well. 

  This topic is designed to cut the process of evolution short and get developers on the right track to defining and building applications that are scaleable, flexible and flow in such a manner that they become almost intuitive.

Comments

Process, Procedure and Flow

6/6/2008 9:50:59 AM

Continued From: Beginning Systems Analysis on 5/8/2008

  Whatever name you or your organization uses for this item, the foundation of a business data system is the Business Process.  Just about every application that can be concieved has a process of use that is associated with it but the underlying difference between a utility application like a "DVD Catalog" and a business App is that the process that drives its use is more than just the process to use the application itself.  So the Business Process is the first key area that has to be analyzed when attempting to build an Application that fills or automates a business need.  In some cases the process that is originally mapped is the old process that involves all of the hand-offs that many different functions will contribute to.  Mapping the process can be done any variety of ways from note pads to tools designed for process modeling like MS Visio or others.

  Recently I had the opportunity to go over a version of a process that I had seen in several organizations that centers around proactive safety and hazard mitigation and documentation.  This discussion goes back to the previous series on early adopters and such where the person detailing the process was, by every definition, very passionate about the activity and the surroundng circumstances.  By the way it was also a good refresher on how to tell a salesman from an advocate (or Evangelist), the salesman could never sound that kind of sincere without also being an advocate.

  So the discussion progressed and along the way I took abunch of notes on the steps involved in this particular process.  It is not that complicated, but then again the best trips from one point to another are the ones that make sense and don't go into too many twists and turns away from the end goal.  So here is the first an most common process model that comes from those discussions. 

  The things that I notice from this initial SWAG at the process is that while it is intuitive and follows a logical path it really does not tell you about the other elements tha make building an APEX Application, or any other for that matter, easier or more intuitive.  An information system is often defined as being a collection of Processes, People and Data System that achieve a goal or set of goal through integrated interaction.  So we have the process but now we need to find the other things involved.  So this is the next evolution of my process diagram that is more commonly referred to as a swim lane process flow.  It defines the lanes that represent the responsibile party to the activity or decision in the process.

   Now I have the people and the process that is happening now.  So all I need is to understand what data systems are currently interacting with the process and at what points.  What I know is that the data managed is largely captured on a small card that is roughly the size of 1/4 a sheet of paper.  It is double-sided and has a number of items in the form.  There is other data involved as well but this card is the initial point of entry when data is captured. 

  For the initial stages of good systems analysis and design the documenting of the process flow for the current state is essential to understanding what changes need to be made to improve and automate the process in the to-be state.  When you map the initial process keep an ear out for points of pain from the customer.  But make sure to document what the process is in the now so you have a basis to adress those issue in the next stage.

Update: 06/15/2008 : Got word the embedded files in the Blog were messing with the APEX Blog Aggregator so I went with poting a thumbnail with a link to the file instead.

Comments

- 6/6/2008 11:05:30 AM

How long did it take to get that process in place and documented?
I know a bunch of companies that don't know the process ;-)
Great stuff Jason,
Dimitri

Jason Aughenbaugh - 6/6/2008 12:05:34 PM

This process took all of about an hour once I found the right kind of person who knew the process in question.  When there is more than one group involved the documentation of the process can take longer but if you find a way to get everybody in one room and are a good facilitator you can accomplish a lot in a very short time.  That said the time to get documented depends on who you have access to and how willing they are to walk you through the information.

Process, Stakeholders and More, oh my.

6/12/2008 3:29:31 PM

Continued from: Process, Procedure and Flow on 6/6/2008

So far I have tried to explain that the process of business is the foundation of any type of application that can be built for that business.  There is one more tool that can be very useful fo this evolution of designing and building your application.  It is called a SIPOC.  Not to be confused with Sybok.

What is the SIPOC?

When you look this term up on the net you are going to find a number of references to Six Sigma, DMAIC and such.  Trust me it is really not that complicated.  One of the best references I have on this item is here: http://www.isixsigma.com/library/content/c010429a.asp

SIPOC is an acronym that literally stands for (S)uppliers, (I)nputs, (P)rocesses, (O)utputs, (C)ustomers. The reference comes from a method of process modeling and analysis that seeks to organize this information into one place.

Typically the SIPOC guidance will usually tell you to take a high-level process for this type of analysis but it is also useful at a more detailed level. At this level where the process is broken down into it more or most basic for you can see the interactions of people, process and tools, like data systems

For your pure enjoyment, or a reason to laugh at me.  I cleaned up my SIPOC utility and put it HERE with the items for my previous process drawings in it.  I also had to post another drawing with the corrisponding numbers for the process references.  It is built in APEX which was built in APEX and helps me to build applications in APEX too.  Circular Definition, anyone?

 

Anyhow, I find this tool really cut to the chase in determining the process and the key elements about the process and its users.  When you take this items to a good level of detail the system interactions with the process and the people involved really have a way of standing out and it make the task of designing the application and the underlying datamodel a bit easier and more consistent.

Updated Note:  Please keep in mind that the SIPOC Application has an output that I was still experimenting with and haven't yet perfected.  Also, feel free to add your own rows and see how this (very basic) application works. jda.

Update: 06/15/2008 : Got word the embedded files in the Blog were messing with the APEX Blog Aggregator so I went with putting a thumbnail with a link to the file instead.

Comments

bagslead - 3/23/2009 10:56:21 AM

this article is very useful for me ,thanks for sharing.
http://www.bagslead.com

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