JD Edwards ERP has 3 areas of expertise: 1. Functional - Business Analyst, 2. Technical Programmer - Developer and 3. CNC - System Administrator and Architect.
1. Functional - Business Analyst
Business subject matter expert on one or more of the JD Edwards modules (Financials, Manufacturing, Transportation, Sales, etc...) often they started as a JDE user, the power user and gradually developed the skill to support the business aspects of JDE. Else, they might have a business degree and come into JDE on the job as a Business Analyst. Functional person seldom has any programming or development experience.
2. Technical Programmer - Developer
Developers are trained in the software development and programming tools that translate the business requirements as identified by the functional into programming code. Sometimes these individuals simply modify existing JDE objects and in other cases, develop entire suites of applications using EnterpriseOne development tools including the Report Design Aide (RDA), Table Design Aide (TDA), Business Function C-code design tools and others using JDE's Change Management System, Object Management Workbench.
3. CNC - System Administrator and Architect
Configurable Network Computing or CNC is a catch-all function comprising all that the two positions above do not cover including, Installation, Upgrades, Migrations, Updates, Change Management, System Administration, Security, Performance Tuning, Package Build and Deployment and over-all Architecture. CNC also refers to the systems analysts who install, maintain, manage and enhance the JD Edwards ERP architecture.
The CNC title is taken from the term ‘Configurable Network Computing’ which describes the overall JDE architecture combining mixed hardware, operating systems and databases to work together seamlessly. CNC technology continues to be at the heart of JD Edwards EnterpriseOne architecture and will play a significant role Oracle's Fusion Architecture initiative. Now a division of the Oracle Corporation, CNC is JD Edwards's client-server proprietary architecture and methodology that implements its highly-scalable enterprise-wide business solutions software that can run on a wide variety of hardware, operating systems and hardware platforms.
Saturday, May 16, 2009
Friday, May 15, 2009
Security Policy
Security policies are an absolute must ground-work for any organization providing the virtual glue to hold it all together. Before we begin about policies, let’s talk a little about trust as a central theme in many policies. Some policies may not be written because there is trust that people will do the right thing but needed because people don't always do the right thing. Ideally you want to trust all resources, but that is unrealistic. Buggy hardware and software are commonplace. Try to implement controls and procedures to minimize the impact when a failure does occur. Trust of employees and users develops over time. Different categories of employees should be trusted at different levels ensuring level of access is commensurate with level of trust.
When looking at trust, you have three basic models: 1. Trust everyone 2. Trust no one and 3. Trust some people at some time. In today's world it is not very common to find organizations that follow the model of trusting everyone all of the time or trusting no one at any time. The most common model is to trust some people some of the time and build trust over time. Also keep in mind that it may be appropriate to apply different trust models to different parts of the organization.
My experience in the field has consistently shown that security policies tend to elevate the level of tension in any given situation with the fact that people don’t like rules and restrictions in their activities. Everyone tends to view security needs differently: 1. Users are concerned about being able to get their work done without a lot of controls. 2. System support personnel are concerned about the ease of managing systems under tight control. 3. Management is concerned about costs versus protection. Getting all to agree of a policy is impossible so best is to try a Win-Win compromise.
To some extent everyone should be concerned of security policies as everyone is affected by them. The system users are typically affected the most as they see the policies as a set of rules to regulate their behavior making it more difficult for them to accomplish their job. The people who have to support the infrastructure are concerned since they are the ones who have to implement and comply by many of the policies. For example, a policy that requires all Windows Servers to be installed according to a baseline security standard would require more work on the part of the system administrators, not only for the initial install, but also for the system upkeep.
When planning policies, some organizations will go overboard and come up with something that will be impossible to implement and comply with. The bottom line for policies is they must take into consideration the balance of protection with the level of productivity hit. Policies should be concise and easy to read and understand. One thing to keep in mind when developing a policy is how it will affect legacy systems and other infrastructure that is already in place. Once the policies are fully approved, they should be made available to all users who are affected. Finally, all policies should be updated to reflect changes in organization or culture.
One of the major goals of a policy is to implement control. Deciding on the level of control for a specific policy is not always clear-cut. The security needs and the culture of the organization will play a major role when deciding what level of control is appropriate. If you make policies too restrictive or too hard to implement and comply with, they will either be ignored (not implemented) or people will find a way to circumvent the controls in the policies.
When looking at trust, you have three basic models: 1. Trust everyone 2. Trust no one and 3. Trust some people at some time. In today's world it is not very common to find organizations that follow the model of trusting everyone all of the time or trusting no one at any time. The most common model is to trust some people some of the time and build trust over time. Also keep in mind that it may be appropriate to apply different trust models to different parts of the organization.
My experience in the field has consistently shown that security policies tend to elevate the level of tension in any given situation with the fact that people don’t like rules and restrictions in their activities. Everyone tends to view security needs differently: 1. Users are concerned about being able to get their work done without a lot of controls. 2. System support personnel are concerned about the ease of managing systems under tight control. 3. Management is concerned about costs versus protection. Getting all to agree of a policy is impossible so best is to try a Win-Win compromise.
To some extent everyone should be concerned of security policies as everyone is affected by them. The system users are typically affected the most as they see the policies as a set of rules to regulate their behavior making it more difficult for them to accomplish their job. The people who have to support the infrastructure are concerned since they are the ones who have to implement and comply by many of the policies. For example, a policy that requires all Windows Servers to be installed according to a baseline security standard would require more work on the part of the system administrators, not only for the initial install, but also for the system upkeep.
When planning policies, some organizations will go overboard and come up with something that will be impossible to implement and comply with. The bottom line for policies is they must take into consideration the balance of protection with the level of productivity hit. Policies should be concise and easy to read and understand. One thing to keep in mind when developing a policy is how it will affect legacy systems and other infrastructure that is already in place. Once the policies are fully approved, they should be made available to all users who are affected. Finally, all policies should be updated to reflect changes in organization or culture.
One of the major goals of a policy is to implement control. Deciding on the level of control for a specific policy is not always clear-cut. The security needs and the culture of the organization will play a major role when deciding what level of control is appropriate. If you make policies too restrictive or too hard to implement and comply with, they will either be ignored (not implemented) or people will find a way to circumvent the controls in the policies.
Subscribe to:
Posts (Atom)
