End User Computing

End User Computing

 

On a number of occasions recently, I have been asked about End User Computing. The subject is often a little difficult with feelings running high because of entrenched opinion. However, my general approach has been to say that utilising the ability of subject matter experts is a good thing, but needs to be set within a context and provided governance.

Below I have set out what I see to be a framework for and EUC policy. If you feel it is of value, please feel free to use it.

What is EUC?

Generally, End User Computing (EUC) refers to the practice of systems being developed by non-programmers, where teams or individuals can create working applications that are deployed within the team or for the enterprise.

EUC attempts to better integrate end users into the computing environment by allowing subject matter experts to deliver relevant solutions for specific problems.  End-user computing can range in complexity from users simply clicking a series of buttons, to writing scripts in a controlled scripting language, to being able to modify and execute code directly.

EUC applications should not be evolved by accident, particularly in a regulated environment. Further, such applications should be constrained by governance and best practice.

The Policy Framework

What is the Business Need?

In many businesses Subject Matter Experts (SME’s) are frustrated by lack of technology, support in performing their roles, and indeed their experience may well mean they know best! If SME’s have the ability to create locally used applications why not?

There are clear circumstances in which SME developed solutions are appropriate and these cases can be described through the following classes;

  1. Job Control, scheduling that can be fulfilled through batch processing, shell scripting and sequencing of tasks.
  2. The generation of workflows through the use of appropriate end user tools
  3. The use of appropriate tools to generate end user reports and reporting
  4. Subject matter experts filling acknowledged gaps in the application estate.
  5. Subject matter experts satisfying compliance
  6. Other cases can be agreed with a Design Authority.

Where EUC is applied, it will often be found that requirements for the application are limited. Rather, they can be seen as emergent, the need being held within the imagination of the SME.

These conditions probably mean that the cost of developing such applications are unknown until the work is complete. Even so, it should be recognised there is commercial benefit in embracing this approach.

The potential issues created by EUC

In accepting that EUC will be carried out with best intent, invariably there will be a number of questions raised about the application and how it is delivered into production, these include;

  1. What is the business need being addressed?
  2. How will the product or tool be supported?
  3. Is it fit for purpose?
  4. How will it be maintained?
  5. Does it meet the governance standards and architectural principles?
  6. What (formal) requirements does it satisfy?
  7. How has the product been tested?
  8. Does the product create any side effects?
  9. What is the life cycle for the product?
  10. How is the source code managed?
  11. Where is the source code managed?
  12. Is security in place?
  13. Is shadow technology being developed?
  14. Is the solution auditable?
  15. Is this a replication of a tool used elsewhere in the enterprise?

Scope

It is suggested that EUC is accepted within a limited context.

  1. The use cases are limited to those described above.
  2. The development is in accordance with best practice described below.
  3. All development is in accordance with the security policy.

Best Practice

EUC best practice is described below.

Who will be developing these capabilities?

The EUC supplied capabilities will be delivered by subject matter experts working within an IT supplied framework. This framework will ensure adequate levels of documentation and testing.

Furthermore, a source code management repository will need to be provided, ensuring the capability can be built and deployed via an agreed mechanism, and more importantly recreated as the need dictates.

Where will EUC capability deployed?

It is expected the majority of EUC will be developed and deployed within the departments where the SME’s operate. Among these are likely to be Finance and Marketing departments.

When with this capability be used?

EUC will be used at where and SME can make a significant difference to the operating environment through process improvement, knowledge capture or dissemination.

How

It is anticipated the vast majority of EUC will be delivered through Excel, however this does not preclude the use of other technologies such as the financial tool sets and interpretative tools such as Python.

All code created in this way will need to be subject to;

  1. Defined Requirements – this can be as simple as some descriptive paragraphs.
  2. Formal code review – there must be some oversight and governance that ensure the capability is not going to create issues in the environment.
  3. Documentation – There needs to be an agreed minimum level of documentation describing what the application does and how it does it.
  4. Testing – must be provided to prove the application works to a satisfactory level.
  5. The source code for such applications must be stored in a source repository such as “Git”, ensuring the application can always be recreated.

 

The process

Once a capability has been identified, it is expected the SME;

  1. will log
    1. the need
    2. high level requirements
    3. the proposed solution
  2. The governance team will then review and provide permission to proceed if applicable.
  3. The solution will either be agreed or an alternative suggested.
  4. At this point the SME can create the agreed solution
  5. After testing and review,
    1. the code and test must be lodged in the source repository
    2. The test must also be lodged in the source repository.
  6. The application can be deployed.

Support

It is expected the SME’s who created the capability will in the main be using it, and therefore the same SME’s will need to support the solution this includes periods when the originating SME is absent.

Review

End user created capability needs to be reviewed at regular intervals. This is to ensure;

  1. the need is still current and met by the application.
  2. The capability is not better met from another part of the estate.

Deprecation

The intention is that EUC capability should be deprecated in favour of capability supplied within COTS packages, IT delivered solutions or bespoke packages. For this reason, EUC capabilities may be deprecated post a review.

https://localhost/~iain/ea/end-user-computing.php

Great article

回复
Ian Batty

Leader in Architecture, Strategy and Data

8 年

There's a couple of other issues that I've seen with this approach (please note that I am entirely in favour of end users developing these kind of applications) 1. How do we ensure that the information being consumed by the end user application is 'correct' or trusted? 2. How do we ensure that the results (aka the knowledge created) of the development become 'corporate' otherwise you have just allowed a(nother) stove pipe to be developed. If you can address these issues then you truly can take advantage of the people best placed to properly solve the issues that they currently face

回复
Fraser Hay

A visionary coach, consultant, author, prompt engineer & keynote speaker. A mastermind of strategic thinking, who helps individuals, entrepreneurs & business owners to plan, document, execute & automate their thinking.

8 年

excellent post Iain

回复

要查看或添加评论,请登录

社区洞察

其他会员也浏览了