August 1, 2014
Request Management is the process of managing all products, applications, and projects across an IBM Notes organization that will support the business strategy, drive efficiency and effectiveness, manage risk at acceptable levels, and achieve regulatory compliance. The purpose of having a Request Management policy is to outline a strategy for ensuring the products, applications, and projects providing the highest value to the organization are funded. Your company may or may not have all three types of requests.
Request Management is the responsibility of the senior management team. Depending on the organization, this group could be called the Product Committee, Steering Committee, or even the Board of Directors. The critical point is that this team is made up of senior managers in the company, and it has responsibility for all products, applications, and projects across the entire IBM Notes organization.
Request Management includes the following:
- Defining and maintaining an enterprise business strategy
- Defining and maintaining an inventory of all initiatives
- Aligning initiatives with the business strategy
- Evaluating and approving/rejecting business cases
- Providing oversight control and decision making for all initiatives
- Ensuring business ownership of all initiatives
The guidelines below will take you from a range of business requests to a prioritized list of authorized requests that are fundable.
Defining the Business Strategy
Before Request Management work can begin, the business strategy must be defined to the Board and communicated throughout the organization. For example, the company may decide that they are going to expand their market into South America, focus on organizational excellence, or provide world-class customer support. Each of these strategic initiatives will be aligned with proposed projects to ultimately determine which projects receive funding and which do not.
Before beginning to review new requests against the business strategy, you must first determine what you already have. New and existing requests must be considered together in order to make the best decisions. An accounting of all requests across the organization in the form of an application inventory is an essential step in Request Management.
Application Alignment with the Business Strategy
During the annual planning cycle, each current and new request should be evaluated to determine which requests match strategic objectives. As part of this evaluation, a process must be established that will allow for an “apples to apples” comparison of disparate requests that includes the application inventory. Participants in this process should include the heads of each business unit or their designate, as well as the CIO.
In addition to the above considerations, a technology risk assessment should be done to determine the likelihood of success. The risk assessment should include the hardware cost, software costs, and integration points required, as well as the ongoing support of the application after the initial development has been completed. This assessment should also include the number of people impacted by the application, the magnitude of that impact, and what training or retraining would be required.
Most IBM Notes organizations cannot fund all their requests. Prioritization is necessary in order to select the best requests.
Request Management provides a number of benefits to an IBM Notes enterprise. However, there are a number of challenges created by implementing a Request Management strategy. First, there is the human element. Request Management requires a commitment from the business and IT in order to work together effectively. Request Management requires a group consensus for moving projects forward. This means that the process of request management requires an additional time constraint in order to work effectively. However, this process should result in significant time savings in the future. Second are the realities of the business. Business priorities change over time. In order to react to market change, request status for all requests must be updated on a regular basis.
Implementing a Request Management strategy where one does not already exist can be a daunting task. Despite the challenges, steps should be taken to begin the process as soon as possible, and improve upon that during each subsequent planning cycle.
July 30, 2014
If you’ve been keeping up with our blog, you’ve seen our previous two blog posts in this series on options for XPages mobile development in the enterprise: IBM Dojo Mobile Controls and the Unplugged XPages Mobile Controls. This post will explore a third option: the jQuery Mobile Controls.
A Brief History
How to Use jQuery Mobile
The Pros of jQuery Mobile
A huge benefit of jQuery mobile is that because it’s so popular, there’s a vast amount of add-ons, resources, and documentation out there to get you going, including demo applications and examples of sample code.
Another pro is that when you download the source files from the jQuery Mobile website, you’re able to use their custom theme builder. Rather than just downloading the default colors, you can apply your corporate style guide to the source code that you’re going to download, and it will make it look like it’s a custom designed application for your environment.
The Cons of jQuery Mobile
Performance is the biggest downside. jQuery is historically quite slow due to being heavy on processes. This could be less of an issue if your users are running newer devices. But for older, lower processing speed devices such as an iPhone 4 or a 2-3 year old Android device, performance will be an issue. Loading pages that have a lot of data can be troublesome, and you could end up running out of memory if you didn’t tailor your page structures accordingly with smaller numbers of view entries. You must know your end users, and understand what devices they’re going to be using in the real world.
Your users are going to be downloading jQuery, JQM, and Dojo, so if they have a slow network connection such as 3G, then they’re going to have slowness issues. To fix this, you can (inadvisably) disable Dojo across the entire application, but you’ll lose the functionality of features like buttons, and at that point you’ll lose a lot of the benefits of using XPages.
Integration into Domino and co-existence with Dojo is problematic. However, if you’re on a version of Dojo older than 1.8, this won’t be an issue and everything will work well.
Whether or not jQuery Mobile is your best option depends on the specific needs of your organization and the nature of your applications and environment. A few other frameworks for creating XPages mobile Web applications include:
Watch our webinar replay on jQuery mobile, here.
July 25, 2014
The success of the mobile business application you develop depends, in part, on how well you are able to exceed your users' expectations with a good user experience. Apple's iOS 8 mobile operating system, set to release this fall, will give mobile developers never-before-seen tools to make their mobile enterprise apps more useful than ever. According to Apple, this release is the biggest for developers since the introduction of the App Store. It will include over 4,000 new APIs and deeper access to iOS capabilities.
Utilize the following iOS 8 features in the next mobile business app you develop, and you’ll exceed your end users' expectations and improve end user adoption.
In iOS 8, the Touch ID feature will be extended to work in third party apps. Touch ID is a fingerprint reader on the home button. It reads the user’s fingerprint, stores it securely, and unlocks functionality when enabled. This feature will allow developers to build an app that lets end users sign into their mobile business apps using only their fingerprint - no password required. The user’s fingerprint data is secured and never accessed by unauthorized parties. After last year’s widespread security breaches, keeping information secure should be top of mind. The Touch ID feature could be useful in any app, but especially useful in business apps that send or receive sensitive information.
PhotoKit and Camera API
With PhotoKit, developers can enable their apps to edit photos directly in the device’s camera roll instead of having to import them into the enterprise app first. With this feature, developers will be able to provide to their users photo manipulations such as filters. PhotoKit will be helpful in any mobile business app that uses the camera feature. Additionally, mobile business apps that use the device’s camera will be able to have precise control over settings such as aperture, focus, and white balance.
CloudKit is a data transportation feature that sends and receives data between Apple’s iCloud Drive servers and a user’s device. It eliminates a developer’s need to write server side application logic. Using CloudKit, developers can use the full power of iCloud Drive in mobile business apps, and enable users to sign in with their Apple ID. Apple is providing CloudKit for free as long as a user doesn’t surpass certain usage limits.
iCloud Drive allows users to easily drag and drop files to iCloud on one device, then access the file from any device that’s running iCloud. In the enterprise setting, IT Departments will be able to set up rules for controlling which apps can open documents from iCloud Drive. Apple announced that iCloud Drive will integrate with third-party cloud services. It’s speculated that Box may be one of these services, but we won’t know for sure until the operating system launches this fall.
For more general use, the new mobile operating system comes with beefed-up enterprise security and productivity features like:
- Ability to enable S/MIME controls in each mail message
- Ability to see colleagues’ availability when scheduling a meeting in Calendar
- Easier access to corporate documents with AirDrop
- An interactive notifications feature that lets users quickly respond to a notification like a new calendar invite without leaving the app they’re in
iOS 8 is a huge release, both for developers and everyone else. The new features add flexibility that helps developers write better apps for their users. Each new feature is considerate, and will give users a more customized experience. Take advantage of these new features to make your end users happier and more productive, and to ultimately improve end user adoption.
July 23, 2014
Updating your IBM Notes Domino applications to the latest release can be a daunting task. However, keeping your release current will result in fewer problems overall. The greater the leap between releases, the more potential for problems. Having a Domino Upgrades policy in place will aid Notes Domino administrators in executing successful upgrades.
An effective Notes Domino upgrade involves a significant amount of planning. The high level steps include:
- An Environment Review
- An Infrastructure Review
- An Application Review
- Upgrade Implementation
The Environment Review
It’s important to create a separate test environment and test at each step of the process. This protects the organization from unplanned application downtime associated with the upgrade. Downtime can come in the form of a scheduled event, such as the time when an actual upgrade is going to take place, or an unscheduled event, such as when an unexpected application error prevents the application from being used.
Reviewing the environment is essential for a smooth migration. The more issues uncovered during the environment review, the lower the risk. There are two parts to the environment review: infrastructure and application.
There are a number of areas that should be considered when reviewing the environment. Each of the items listed below could have a negative impact on the upgrade if not evaluated fully.
- How the server is managed and how the Notes internal processes are functioning (adminp, catalog, design, amgr and http). Make sure you understand what each server task is doing so you can confirm it’s still functioning correctly after the upgrade.
- Review the Notes.ini settings to identify items that are missing or can be removed. The notes.ini can give clues about what server tasks are running or what third party add-ins may also need to be upgraded.
- Review how replication is being used and its model within the organization. Review the size and timings of replications, the number of threads, which servers are initiating the replication and the type of replication being done. Knowing the replication topology will aid in determining the order in which servers need to be upgraded.
- Review what agents are scheduled, how long they take to run and when they run. Performance benchmarks will help identify performance issues the upgrade may have caused.
- Review the Access Control Lists (ACL) for the system databases and Templates. Depending on the size of the upgrade, this may be a good time to perform ACL and group clean up.
- Diagram the configuration of servers and users across the network. A complete network topology in addition to the replication topology will give you the order of server upgrades.
You must also determine the level of Notes monitoring that exists with the current environment. You need to know what monitors you are currently relying on for keeping on top of server health. An upgrade that disables a monitor for whatever reason may result in longer than planned downtime or the omission of a critical event. You should document the types of alarms used including database, mail, disk usage and memory utilization. Make sure that test plans exist to trigger the events so you can be sure they still function correctly after the upgrade.
An analysis of all Notes applications should take place that documents the real usage history of all applications in use throughout the organization. Gaining an understanding of which applications are in use, who is using those applications and how much will provide invaluable insight necessary in planning the upgrade strategy. Time spent migrating unused applications or reapplying template customizations to unused templates is time better spent elsewhere.
An upgrade analysis should be performed to determine where the new Notes Domino version will have an impact on the existing applications. Areas of concern include obsolete functions, modified views in the Domino Directory, new formulas and new fields.
Once the impact of the new release is well understood, a simple application should be selected to benchmark the time and resources required to complete the upgrade and to make the necessary design changes for each application.
Once the benchmark application has been upgraded, a decision needs to be made regarding the readiness of all Notes Domino applications. An investigation of all areas identified during the benchmark that may impede the upgrade should occur to determine the organization’s readiness.
An area of concern is maintaining customizations that have been made to standard Notes templates. Prior to any upgrade, it’s important to identify all customizations so that they can be reapplied to the new version of the template provided in the upgrade.
Requiring a strict adherence to an organization’s Notes Domino Upgrade Policy should be required in order to effectively support the overall business objectives of the organization. Adhering to this policy will provide management with the ability to manage costs effectively, minimize risks associated with an upgrade, and remain in compliance with organizational standards and applicable regulations.
July 18, 2014
Back in the early 1990's, a Lotus Notes developer only had to contend with forms, views, and @ formula to make an application work in Lotus Notes.
This was then augmented in 1996 with InterNotes Web Publisher for an R4 server, and we started putting in passthrough HTML into views and hide/when for some fields to only show in a Web browser. That all becomes standard fare in R5, and then it all goes a bit stale for a long while.
Roll forward to 2009 and IBM releases XPages to an unsuspecting developer community. They are highly demanding of change, but don’t know what is about to happen to them.
IBM takes a group of developers to three workshops around the world and has them explain to a selected audience what XPages is and how to develop in it. The result is an instant success with the developers in the room and everyone is hyped up about what they might be able to show at January’s Lotusphere conference.
What IBM did was add Java Server Faces (JSF), and add it and Dojo to the Domino http engine. In the process, they managed to bring about the most significant change in Notes and Domino development since the introduction of Lotusscript.
Developers could now separate the business logic from the data and from the user interface (UI). These had all been interwoven in previous versions mostly because of Lotus/IBM’s mantra of backwards compatibility. It’s a great mantra to have and even better that IBM has managed to keep it since version one of Notes.
To make things easier, we develop our XPages and Unplugged applications using a process that highlights how things have changed. Here’s how it usually goes:
- Design and develop the UI and get it signed off by the users. This pays massive dividends in terms of development time and user acceptance testing. Everyone has a very clear understanding of what it's going to look like in the end, and it's familiar when the User Acceptance Testing (UAT) process starts.
- Build the mechanics behind the buttons. Now that you have the interface, it has to do something to be useful, and this is where you start to codify the business and application logic that has been agreed in the requirements gathering phase.
- Date loading of real style data will mean that the testing has validity.
- Internal testing comes next, and it's vital that this is built from the statement of work and requirements gathering workshops. The bug list that comes out of this gets fixed before UAT.
- User Acceptance Testing should be done next and with a limited period of time to be completed. This allows the users the chance to focus on the app and make sure it does what they need.
- Bug fix from the UAT is the penultimate stage of the process.
- Documentation of what each Custom Control and XPage does and its dependencies is finalised. We use our CIAO! product to help create a record of the design process so that others can see what was done when, and by whom. We also keep this as an internal record and make it available to the support team so the application is easier to support going forward.
So now you know how we approach XPages development here at Teamstudio, but how does that demonstrate how XPages has changed your development? Well to start with, you could not separate the data from the UI in traditional Notes coding. We couldn’t build what it's going to look like and then start adding the code underneath that. When you’re building Notes forms and views, it's not possible to separate how they interact with the data at all. In fact, they are the things that define the data and how it works, and this is still true even when designing XPages applications.
Then again, we could not build the app at all without the data structure to work from, so it’s vital that if you are starting from zero, you get your forms and views right first.
So, the way we approach application development now has fundamentally changed the order in which we pick things up to make the application. It's also meant that we can structure the build of applications so that no matter what they are, we can approach them in the same way as any other application development platform would.
July 16, 2014
It’s commonly accepted that responsive web design is the way to go for developing websites and mobile apps. Everyone agrees that having a flexible user interface that provides an optimal viewing experience across various devices is important. Good user interface design practices can make a mobile app look better and function more easily. In fact, UI decisions are some of the most important decisions developers have to make, because the largest factor of poor adoption of mobile apps is poor User Experience: both UI design and performance.
Apple is an example of a company who has introduced important innovations to the way users interact with computers, music players, and phones. Some of their success can be attributed to their attentiveness to consumers’ need to have a good-looking device that’s a pleasure to interact with.
But how can you, mobile application developers, achieve good user interface design with a flexible UI? You have quite a few options even after you decide on a mobile architecture. One of the easiest and most popular options is to use a mobile application framework. Mobile application frameworks are software that aid developers in creating mobile apps. Each of the vast number of frameworks supports varying combinations of mobile application platforms. No matter your mobile application platform needs, you can be sure there’s a framework to help you achieve a responsive UI.
A few of the most popular frameworks that allow responsive web design for Web-based (mobile Web or hybrid) apps include jQuery Mobile, Top Coat, Twitter Bootstrap, Kendo UI Mobile, and Sencha Touch. The following is a brief summary of each of these frameworks.
jQuery Mobile ranks as one of the most commonly used mobile UI frameworks for mobile Web and hybrid apps. It’s free and open source, and provides a mobile user interface that imitates the same usability of jQuery’s desktop product. The framework has great documentation and a huge number of plugins, themes, tools, etc. It’s criticized for slow performance in mobile browsers, but the team behind jQuery Mobile is reactive and regularly works on issues like this.
The Twitter Bootstrap toolkit is a responsive front-end framework that includes base CSS and HTML code for elements such as typography, forms, tables, navigation, buttons, grids, and more. Bootstrap is ever evolving, with updates coming out on a regular basis. One criticism of this framework is its performance in a mobile only setting. While you do need a working knowledge of web development concepts like HTML and CSS to get the ball rolling with the bootstrap mobile framework, it’s not out of reach for those willing to invest a little time into learning these concepts.
Kendo UI Mobile
The Kendo UI mobile framework provides both app framework functionality and 13 built-in widgets, with the freedom to create custom widgets as well. Although licensing starts at $199, it comes with excellent documentation and support for developers who make the investment. The framework has a flexible UI with adaptive widgets that change based on the platform to copy the native look of the user’s device, depending on which platform it runs on.
Mobile application frameworks like these are unlocking huge opportunities for innovation. Have you used any of the above frameworks for your Web-based applications? Did we miss your favorite? Let us know your experience in the comments section below!
Haven’t decided on a mobile architecture yet?
Read this free white paper to find out which is best for your company.
July 11, 2014
Teamstudio Build Manager is a tool for the comprehensive control of the movement of Notes database templates from one environment to another. It improves efficiency by automating the steps necessary to make a template ready for the next environment, and mitigates risk by ensuring all necessary steps are completed as specified, thus reducing the risk of human error. It assists with compliance to regulatory standards by ensuring the enforcement of segregation of roles, all at the push of a single button! Whether you’re an IBM Notes Administrator or Developer, it makes your life easier with one-click builds.
The Promotion Process
Build Manager allows you to create promotion path documents, which automatically create a template from your design database and promote it through the process to production.
The time to promote varies and is contingent upon the size of the design being promoted, and the network bandwidth. The promotion process starts with creating a backup copy of the existing code to be used as a rollback if the promotion fails.
A Technical Look at Teamstudio Build Manager
There are four .NSF components to Teamstudio Build Manager, an executable file, and a DLL file. The code is run from a Notes client, so only the database is installed on the server. The executable and DLL files are installed on each PC that’s being used for Build Manager for promotions. Build Manager users need to be able to write to the Notes and Notes/data folders. The four .NSF components include the following.
- The Build Manager Configuration Database is required and holds all configuration and build documents.
- The Template Registry Database is optional, stores all versions of code promoted out of development, and is the staging area for promotions to QA/UAT/TEST and production environments.
- The Workflow Approvals Database is optional and is used to configure approval workflows when approvals are needed to promote code to the next environment.
- The Agent Parameters Database is optional and is used for the run agent step that is described below. It takes information from the configuration documents and provides them as easy to access variables to be used in LotusScript agents as part of the build.
The actions you can automate using Build Manager are detailed below.
- Build Path: This step allows you to define the template registry the template will be stored in.
- Promotion Path: This step allows you to define where the template will be placed so the target application can have the design automatically refreshed/replaced.
- Make Version: Uses details from the CIAO! configuration document (if you have licensed a copy) to create new versions of the application.
- Design Audit: Uses Teamstudio Analyzer auditor (if you have licensed a copy) to search for design issues and report on them relative to failure thresholds.
- Search and Replace: Uses Teamstudio Configurator (if you have licensed a copy) to perform an automated search and replace on the target database to identify and change text in the promoted template.
- Database Properties: Automatically changes the following database properties: Title, Categories, Inherit From, Template Name, TemplateBuild.
- ACL: Automatically sets ACL properties and roles using values either defined in this step or derived from a Stored ACL.
- ACL Entry: Automatically adds ACL entries (people and/or groups) to existing ACLs.
- Copy Database: Automatically copies the target database to another location.
- Compile LotusScript: Automatically compiles all or specified LotusScript in the design.
- Element Properties: Automatically changes the following design element properties: Prohibit Design Refresh, Propagate Prohibition, Design Element Inheritance, Design Element Comment.
- Enable Agents: Automatically enables or disables the selected scheduled agents.
- Set Agent Server: Automatically sets the server on which the agent runs for the selected scheduled agent(s).
- Set Agent on Behalf of: Automatically sets the user the scheduled agent will run under.
- Refresh Design: Automatically refreshes/replaces the design of one or more databases. There is an option to ignore any prohibit flags in the database to be refreshed so you can ensure the design in the target is what passed testing.
- Run Agent: Automatically runs any agent in any database. This step allows for custom promotion processes that include steps not defined as standard in Build Manager.
- Sign Database: Automatically signs the database from a stored or attached ID. The options are the same as if using the Administration Client.
- Email Notification: Automatically sends an email to one or more individuals or groups when the build is successful.
These steps are configured to match your existing processes, so all of them may not be necessary. But using this tool is the perfect time to update your processes to be in line with environment best practices.
-John Coolidge, Technical Director
July 9, 2014
Today’s mobile marketplace is characterized by ceaseless innovations, rapid changes, and endless updates. It’s an explosive environment that requires mobile applications to be quickly delivered to users who have multiple demands ranging from various screen sizes, operating systems, bandwidths, device capabilities, and user experiences.
These characteristics present challenges for mobile developers, especially with today’s advances in handheld devices and mobile application frameworks: software that aides developers in creating mobile apps such as jQuery Mobile, Kendo UI, and Apache Flex. Each of the vast number of frameworks support varying versions of platforms such as iOS and Android, development languages such as Java and C++, and user interface features such as widgets and customization. Add to these decisions about whether the framework should support certain hardware features, be free or open source, support SDK or encryption, and whether it should support the mobile Web, hybrid, or native app architecture, or all of these, and it’s easy to see the challenges developers face.
Along with the framework decision, should developers use the wrong client architecture – the mobile Web app, the hybrid app, and the native app that differ significantly – it can lead to poor user experience and adoption. As a result, great care should be taken when choosing the appropriate mobile app architecture.
Here’s a breakdown of the three architectures and why you would or wouldn’t use each.
The Mobile Web Application Architecture
Apps using the mobile Web app architecture run on a mobile browser. The browser hosts the app’s presentation layer that’s created using HTML5. Because of this, the interface looks and behaves like a traditional website, but is designed for the mobile device.
The Hybrid Application Architecture
The hybrid app architecture addresses the mobile Web app architecture’s inability to access device sensors such as Bluetooth, GPS, accelerometers, and cameras. It also enables cross-platform support, building HTML5-based applications that run in the browser window, mimicking the look and feel of a native app.
With the hybrid app architecture, developers can reuse existing code with minimal tweaking, and there is access to all native features. Using the native components also results in a richer user experience. Some issues to consider include that the UI is the lowest common denominator between platforms, and performance varies between platforms.
The Native Application Architecture
With the native app architecture, the application is custom built for a targeted device’s operating system and its Application Programming Interfaces (APIs) and Software Development Kit (SDK). The developer can use standard Graphical User Interface (GUI) components from that platform’s SDK. As a result, users receive a richer overall experience, along with excellent performance, and native look and feel.
From a development standpoint, the native app architecture makes it possible to build complex, rich, responsive applications that supply excellent performance with no need for mobile programming skills. The native app architecture provides users with a high quality user experience and user interface design with very few slowness or lagging issues. However, the native app architecture may need installation, upgrading, and uninstallation, and it’s device and platform-specific. Additionally, some businesses have reported somewhat higher costs due to development time.
In conclusion, a mobile Web app architecture is appropriate for creating a simple mobile-optimized version of an existing website. The hybrid app architecture works well for business mobile applications and content applications, and apps with a basic user interface and functionality requirements. The native app architecture works well for applications that can’t compromise on the user experience or performance, and where cost savings and productivity gains from cross platform code sharing is not a goal. Which mobile app architecture is best depends on your specific needs. Considering the above benefits and issues will begin to point you in the direction that’s best suited for your company.
July 4, 2014
IBM Notes is easy to use and allows rapid application development, but very few organizations know how many applications are in place, where they are, or what they do. Further, changes to applications are made ad-hoc and many times directly in production with no accountability and no change management process.
The result of this lack of control is far-reaching, including:
- Lack of automated processes leading to errors and bottlenecks
- Poor end user satisfaction from the application
- Slow turn-around of change requests by development
- Costly downtime happens more often
- Difficulties in functioning as a development team with no version control system
- Disruptive, time-consuming, costly and labor intensive regulatory audits
- Lack of global visibility into security and auditing of ACL settings across the entire enterprise increases risk
This leads to wasted resources, wasted space, and wasted opportunity for business benefits. Ultimately, the potential ROI from Notes will not be achieved, which sadly has the effect of causing management to consider other platforms. However, given the cost of “rip and replace” strategies, the only sensible option is to establish a set of fresh policies for your IBM assets.
To effectively manage your IBM Notes infrastructure, you need to develop a strategy with policies, processes, and tools necessary to address your governance requirements. It’s important to consider the human element in managing these processes. You have to be able to track “effective” application access and have the ability to create an audit trail of application access and changes. Automation is the best way to implement control, deliver compliance, and to manage risk.
We’ve broken the process down into the five traditional areas of the application lifecycle: Requirements, Design, Development, Test, and Production. You begin by auditing your existing policies and practices in these areas. Only then can you consider how to implement Application Lifecycle Management (ALM) for Notes. The following information describes the five key areas you should be concerned about when it comes to managing your IBM Notes applications.
IBM Notes Requirements Policies
Requirements policies are those tasks that go into determining the needs or conditions for a new or altered application. Requirements can start out as just requests, which can come from almost anywhere across the organization. Requirements must be measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for application design.
Design policies are where the technical blueprint of the system is created. This is done by designing the technical architecture, and choosing among the architectural designs of software, hardware, and infrastructure that will best suit the organization’s current and future needs. This includes designing the systems model, graphically creating a model from a graphical user interface (GUI), GUI screen design and databases, to placement of objects on the screen.
Development policies transform the design into a physical system by building the technical architecture, database and programs that will be used in the system.
Test policies provide processes for testing the developed system. Test conditions were created during the Design phase, and are conducted by comparing expected outcomes to actual outcomes. If these differ, a defect is generated and you have to back-track to the development stage.
Production policies address moving the applications to the users of the system. Training is provided to the users of the system prior to “going live”. These policies also include keeping the system up to date with changes in the organization and ensuring it meets the goals of the organization by building a Help Desk to support system users.
Understanding where your organization is with regard to these policies and practices is essential. It’s also necessary to understand how you might begin to implement an ALM framework using these policies within your IBM Notes environment.
All Notes professionals need to start somewhere. Whether you are at the start of your journey to change a simple existing set up or you are making sophisticated tweaks to a mature environment, understanding these application areas will help you grasp the steps needed to achieve effective governing of your Notes environment.
July 2, 2014
Having a documented business continuity plan is an essential part of planning and preparing for serious data breaches and unavoidable natural disasters. Fortunately, according to AT&T's 2012 Business Continuity Study, 86% of companies with revenues of at least $25 million have a business continuity plan in place. However, testing your plan is just as important as having a plan in the first place. In order for your business continuity plan to be effective, it must be tested. Whether your company conducts full-scale tests once a year or more frequently, the following best practices will help your drill run smoothly and will help you report positive results.
Have a BCM Plan
If your company falls under the 14% of those reported above who don’t have a Business Continuity Plan (BCP), this paragraph is for you. The first and most important way to pass your business continuity drill is to have a solid plan in the first place. Before your organization ever suffers a disaster, you must have put in the work to develop a business impact analysis and risk assessment, and shared your plan to necessary personnel. By having a researched and well-communicated plan, you will have taken the first step toward successfully passing your drill.
Test your BCP Frequently
According to Symantec, a shocking 22% of businesses never actually test their continuity plan, or only test it after an emergency takes place. Another 22% say they only test their plan once a year. Running a full-scale test once a year or more gives a business the opportunity to understand how their BCP will do in various crisis scenarios, and gives the BCM professionals the opportunity to address any problems encountered. Testing is the best way to ensure your business is ready for a disaster.
Communicate: “This is Only a Test”
As another important measure, it’s a best practice to label all drill materials clearly with a phrase like "This is only a test." It's important to do so to ensure that if any non-staff or unaffiliated parties accidentally get their hands on the material, they will be fully aware that a real disaster has not taken place.
Get All Hands on Deck
When you’re testing your business continuity plan, it's vital that everyone in the organization has a "hands on" experience. Since a disaster would affect everyone in the organization, everyone in the organization should understand what to do in the event of a disaster. The best way to ensure participation is to communicate the planned drill details and objectives to every department. This way, no one is left in the dark about the importance or significance of the test.
Hire Outside Help
If your company isn’t large enough to house a dedicated business continuity team, or if you need expertise in a specific area, it could be worth hiring an independent consultant or project manager to make sure the test process goes as smoothly as possible. Independent professionals can bring a wealth of industry best practices and methodologies, and can facilitate the drill for you. They can make suggestions based on what is best for your business in terms of things like BCM products and recovery sites, as well as steps to take after the drill is complete.
Incorporate a Mobile Solution
When the unexpected occurs, your company needs a business continuity plan that can be accessed quickly and easily so you can restore operations. Business continuity software brings BCM into the 21st century in such ways as providing a uniform look to your plan’s documents, universally applying personnel record updates, and generating reports, but a mobile solution takes BCM even further. With a mobile solution, you gain access to data anywhere, anytime, even when offline.
Undoubtedly, natural disasters, security breaches, and other catastrophic events will occur. Although that reality may be unavoidable, the repercussions of these events don’t have to be devastating. By exercising these best practices around your business continuity plan, you can ensure your organization will be able to continue operations after a worst-case scenario.
Watch a demo of our mobile BCM solution!