Atlantic Business Technologies, Inc.

Category: Development

Here, you’ll find insights on programming languages, frameworks, and techniques that shape the web and software landscape. Whether you’re a developer looking to refine your skills or simply curious about how things work behind the scenes, this space offers practical knowledge and thoughtful perspectives.

  • Definitive Guide to CSOS Development

    Are you currently developing or planning to develop a Controlled Substance Ordering System, or CSOS? Then you’ve come to the right place. This guide was developed to provide all the information to create such an application in one friendly document. To learn more about how this process took shape, read about Atlantic BT’s web development work for NC Mutual Drug. This work was the inspiration for our writing this guide.

    Background for This CSOS Guide

    The DEA created the CSOS audit process when client-server architecture was the only viable solution. Audit cases exist for both the “sender” machine and the “receiver” machine (i.e. Audit Cases 1 & 2). Atlantic BT’s implementation is a web application, which performs both the client and server actions. Therefore, the documentation in this guide organizes these cases together. In a true client-server environment, the cases are applied appropriately. Atlantic BT’s implementation involves Windows servers and a .Net solution using C#. Information and examples providing guidance on accomplishing validation will use technology-specific references only when necessary. It should be stated that when signing an order with controlled substances, a single digital file must be utilized for signing. This is similar to the real-life scenario in which you would sign a physical document. In Atlantic BT’s application, an EDI 850 file is constructed for signing, and will be referenced throughout as the “order file.”

    Source Documentation CSOS

    Many documents exist and are publicly available for CSOS developers:

    Note: The CSOS Certificate Management documentation is for owners of the digital certificates. If you note the “Manage CSOS Certificates” section, this documentation was created prior to Windows 8 existing and before Google Chrome was a standard web browser.

    Why Does this Guide Use “Audit Cases”?

    AtlanticBT used the Drummond Group to perform the CSOS audit. The Drummond Group uses 13 “Audit Cases” to test all requirements for a CSOS application. This guide provides information on the validation needed to pass each case, and how the audit occurs. Please note that the audit cases in this guide were in place at time of AtlanticBT’s audit; the Drummond Group may add or modify these in the future.

    Audit Cases 1 & 2

    These cases all involve verifying the code and systems use approved FIPS modules.

    Validation

    1. Go to the NIST page listing all validated modules: csrc.nist.gov
    2. Find the module your implementation will be using
    3. Be able to show in your code and on your server you are using the module you specify.

    Audit Cases 1.1, 2.1 These audit cases validate the cryptographic module residing on the machines used in validation.
    Audit Process (Windows) In order to show what version the server is running, open a Command Prompt on the server. Use the “ver” command. AtlanticBT’s solution was deployed on a Windows Server 2012 instance. This is Cert #1894 on on the nist.gov page. Note that this cert correlates to “Software Version 6.2.9200”.

    C:\> ver     Microsoft Windows [Version 6.2.9200] C:\
    Audit Cases 1.2, 1.3, 2.2, 2.3
    Audit Process AtlanticBT showed screenshots of code, and that encryption algorithms were used from Microsoft libraries that were approved within certificate #1894. To prove the code was truly FIPS compliant, the following was performed on a developer machine:

    1. Windows not running in FIPS enabled mode, run validation on a certificate using FIPS approved modules. This should succeed.
    2. Change Windows Mode to FIPS enabled (See Stack Overflow: How to enable FIPS on windows 7)
    3. Windows running in FIPS enabled mode, run validation on a certificate using FIPS approved modules. This should succeed.
    4. Change encryption to a non-FIPS approved method. (This is a temporary code change for auditing purpose only). Run validation on a certificate using non-FIPS approved modules. This should fail.

    Audit Case 1.4 This audit case validates that certificates (called “private keys” throughout CSOS documentation) reside in an encrypted fashion whenever stored.
    Validation Encrypt any stored instances of certificates. Atlantic BT’s solution utilized the AWS S3 service, which can encrypt files using the AES-256 encryption algorithm. Some solutions may involve using a computer’s Certificate Store, which uses encrypted storage.
    Audit Process Show proof on files stored using encryption. If a custom storage solution is implemented, this would involve storing a new certificate and showing the stored file is encrypted.

    Audit Case 3 & 4

    These audit cases involve signing an order with a valid certificate, passing all validation.
    Validation No specific validation needs to be developed, but all other validations must be performed and pass.
    Audit Process An order is signed with a valid certificate, and validation succeeds.

    Audit Case 5

    These audit cases contain many of the certificate-specific validations. They relate to the validations which can be applied to the certificate and information unrelated to the order being signed. In advance of discussing the audit cases, it is important to discuss certificate hierarchy. Many of the test cases involve validating data against the “certificate chain”.
    Certificate Structure There is plenty of information on digital certificates concerning their creation, structure, and use. However, simple summaries are difficult to find. That in mind, the following attempts to offer a summary and correlate it specifically to the CSOS requirements. 1) A “Root Certificate” is created. This is used to create other certificates, and in these, the unique “thumbprint” of the root is contained within its metadata. The DEA has created root certificates specifically for use with CSOS certificates. —> There are “private” and “public” portions of certificates. The “private” portion can be used to create other certificates and are never provided (to avoid fraud). The “public” portions can be used (by anyone) to validate a certificate was issued from the root. 2) A “Sub CA” (Certificate Authority) certificate is created from the root certificate, as noted above. The same structure applies—these certificates can be use to create yet other certificates, and the Sub CA “thumbprint” is contained within the metadata. The DEA has created Sub CA certificates which are used to create the personal certificates. 3) Personal certificates are created for use in signing. Therefore, for all CSOS certificates, the “chain” of certificates is as follows: —> Root Certificate —> Sub CA Certificate —> Personal Certificate
    Server Setup In order to successfully validate certificates, the system performing validation must have the Root and Sub CA certificates installed. Having access to the certificate files is not enough; these must actually be installed. The official CSOS Root and Sub CA certificates, for use with production, can be found here:
    CSOS Certificate Management (deaecom.gov). During development and auditing, a test suite of certificates is used (see: diversiontest.usdoj.gov). The “CA CERT” folder within contains separate Root and Sub CA certificates for use with the test certificates.
    Developer Warning: Make sure the test suite root and sub certificates are only installed on local and dev servers, and not installed on production machines. To install certificates on a local (Windows) machine, use the Certificate Manager. This can found by using the Windows Key and searching for “Manage computer certificates”, or using the MMC Snap in (see: How to: View Certificates with the MMC Snap-in)

    Root and Sub CA certificates correctly installed on a Wondows Machine
    Root and Sub CA certificates correctly installed on a Wondows Machine

    In order to verify these certificates are installed correctly, you can use any browser’s certificate management and import a certificate. The following examples use the ValidOrderThree certificate from the test suite of certificates:

    The left screen shot shows Root and Sub CA certificates installed correctly. The "certificate chain" is complete and valid with the root certificate at the top. On the right hand side, the Root and Sub CA certificates are not installed correctly. The sub CA certificate cannot be found.
    The left screen shot shows Root and Sub CA certificates installed correctly. The “certificate chain” is complete and valid with the root certificate at the top.On the right hand side, the Root and Sub CA certificates are not installed correctly. The sub CA certificate cannot be found.

    Audit Case 5.1 The CSOS requirement for case 5.1 states “The system must determine that an order has not been altered during transmission.” This relates to the original client-server architecture expected when the requirements were established. The order would be created and signed on a client machine, transmitted to a server, and then final processing occurred. This case is designed to verify the data sent from the client machine to the server was not altered. In a web application, however, this may all occur on the same server. The order is submitted and signed through the web application, and all validation could occur prior to final success, all in memory. This is the case for Atlantic BT’s application. In order to provide an auditable result, the code was structured as follows: 1) The order file is digitally signed, which results in a signature file (in memory). This file is a small file containing encrypted (non-readable) data. 2) All other validations are performed on the certificate. 3) Lastly, a verification of the signature file and order file is performed.
    Code Reference (.Net) For signing, the RSACryptoServiceProvider.SignHash Method was used. For verification, the RSACryptoServiceProvider.VerifyHash Method was used.
    Audit Process In order to show success of this requirement, two signing attempts were shown. This was performed on a local machine using Visual Studio, which allows debugging and breakpoints to modify in-memory data. 1) Successful a. Break after SignHash method, show in-memory order file b. Break before VerifyHash method show in-memory order file hasn’t changed c. Show VerifyHash is successful, thus the sign process succeeds 2) Unsuccessful a. Break after SignHash method, show in-memory order file results b. Modify the order file data c. Break before VerifyHash method show in-memory order file has changed d. Show VerifyHash is unsuccessful, thus the sign process fails In a client-server environment, this could be accomplished by simply using a different order file with the generated signature file for verification. In-memory data modification would not be required.
    Audit Case 5.2 This audit case is to validate that the certificate being used to sign the order originated from the DEA for use with signing digital orders.
    Chain Building (.Net) First, a valid certificate chain must be determined. Using .Net, a valid X509Certificate2 object is created from the certificate data. Throughout this guide, the certificate being validated will be an X509Certificate2 object. Next (In .Net), a X509Chain is created, and the Build method is used the verify the chain and build the chain in memory. If the Root and Sub CA certificates have not been correctly installed, this method will fail.
    Validation To pass validation successfully, it should be verified the thumbprint of the found root certificate matches one of the official DEA CSOS Root Certificate thumbprints. At time of documentation, the two DEA root thumbprints are: “9037640ee5c71e4ced76ed88fefa4e051907f7e7” and “f23190647132a900e634badf2a8f35a95bd383d7” The test suite root certificate thumbprint is: “fb1eb3439c28e14014f2ef942f0bdd636bfef467”
    Audit Process In order to show failure for the audit case, a certificate that was not created using a chain originating in a CSOS root certificate must be tested against. There are a few methods to creating a certificate:

    CSOS Development White Paper
    CSOS Development White Paper
    CSOS Development White Paper

    When signing an order using any non-CSOS certificate, the signing should fail, passing the audit case.
    Audit Case 5.3 This audit case validates the generated signature file from signing. Similar to 5.1, this means a signing process should fail if the signature file is modified in transit, whereas case 5.1 related to the order file.
    Audit Process In order to show success of this requirement, two signing attempts were shown. This was performed on a local machine using Visual Studio, which allows debugging and breakpoints to modify in-memory data. 1) Successful a.Break after SignHash method, show in-memory signature file b. Break before VerifyHash method show in-memory signature file hasn’t changed c. Show VerifyHash is successful, thus the sign process succeeds 2) Unsuccessful a. Break after SignHash method, show in-memory signature file results b. Modify the signature file data c. Break before VerifyHash method show in-memory signature file has changed d. Show VerifyHash is unsuccessful, thus the sign process fails In a client-server environment, this could be accomplished by simply using a different signature file with the order file for verification. In-memory data modification would not be required.
    Audit Cases 5.4, 5.5, 5.6, 5.7 These audit cases validates the certificate being used to sign the order hasn’t been revoked. The DEA permanently maintains a publicly accessible Certificate Revocation List (CRL) to check for certificate validity. There are four audit cases pertaining to certificates revoked for a variety of reasons; however, the validation is performed the same way for all cases.
    Determining the CRL for the Certificate The first step in validation is finding the appropriate CRL. The CRL for any CSOS certificate is contained within the metadata of the certificate itself. Unfortunately, this needs to parsed from within a large string. The screenshot provided shows the URL value of the CRL, but this is only part of a string value which contains other certificate information.
    Using Newlines, “URL=”, “cn=”, and “(“ breakpoints, the domain and other CRL information can be parsed. The domain on it’s own will be used to establish a connection.
    Connection An LDAP connection is required to connect to DEA provided CRLs. For .Net, a “LdapConnection” object is utilized. The “Distinguished Name” is required as well, which in the screenshot is all the parameters from “cn=CRL3” through “c=US”, these are the identifiers for the specific CRL.
    Validation In order to be validated, a connection must be made, the correct CRL entry must be located, and the certificate being validated must not be found in the CRL. (If it is found, the certificate is revoked.) Therefore, the following checks should be made:

    Audit Process The audit process for these are straightforward. Revoked certificates from the test suite of certificates are used in signing an order. All attempts should fail.
    CRL and ARL Please see Audit Case 5.9 for additional information which builds upon this CRL validation.
    Audit Case 5.8 This audit case validates the certificate has not expired.
    Validation All certificates have a “Valid To” or expired date within their metadata. If this date has passed, then the certificate has expired. In .Net, there is a “GetExpirationDateString” method. The results can be used to create a Date object for comparison.

    Audit Process Again, this is straightforward. An expired certificate from the test suite should fail validation.
    Audit Case 5.9 This audit case validates that either a Sub CA or root certificate in the certificate chain has not been revoked.
    Validation Once a valid certificate chain has been established (See Audit Case 5.2), and the certificate itself has been determined as not revoked, every other certificate in the chain must be found as not revoked. The process developed for Audit Cases 5.3-5.7 can almost be used for these certificates.
    However, a disparity exists between the test suite and real-world certificates at time of this documentation. For test suite certificates, this CRL check passed validation. When performing tests against a production certificate, this validation failed. A different attribute was found when using the LDAP connection for these certificates: “authorityrevocationlist;binary”. These connections contained attributes for both the CRL and the ARL. Therefore, the resulting validation occurs for all certificates:

    • Connect to the LDAP
    • Check for the CRL attribute.

    * If this was not found, validation fails for being unable to check the CRL. * If the CRL check was successful, and the certificate was found (thus revoked), validation fails. * If the CRL check was successful, and the certificate was not found, processing continues.

    • Check for the ARL attribute.

    * If this was not found, validation succeeds. (Because it is not required to check ARL, and this will not exist for personal certificates). * If the ARL check was successful, and the certificate was found (thus revoked), validation fails. * If the ARL check was successful, and the certificate was not found, validation succeeds.
    Audit Process A valid certificate linked to a revoked Sub CA certificate from the test suite should fail validation.
    Audit Case 5.10 This audit case validates that either a Sub CA or root certificate in the certificate chain has not expired.
    Validation Once a valid certificate chain has been established (See Audit Case 5.2), and the certificate itself has been determined as not revoked, every other certificate in the chain must be found as not revoked. The process developed for Audit Cases 5.8 can be used for these certificates.
    Audit Process A valid certificate linked to an expired Sub CA certificate from the test suite should fail validation.

    Audit Case 6

    CSOS Development White Paper

    This audit case pertains to the drugs specified in an order, and that the signing certificate has the authorization to purchase these drugs. The DEA has seven “schedules” or “schedule access” for controlled substances. (See:
    Controlled Substance Schedules    ) These are 1, 2, 2n, 3, 3n, 4, and 5. Each CSOS certificate contains in its metadata the list of authorized schedules that can be purchased.
    Order Schedules The order file which is being signed must contain the list of drugs in the order, and the schedule access for each drug. The list of these schedules must be gathered for comparison.

    Certificate Schedules Each certificate contains many fields of data. The metadata field for OID “2.16.840.1.101.3.5.4” contains the 8-bit field related to available schedules. (See CSOS Certificate and CRL Profile (PDF) 6.2)
    Please note it is only the last 8-bit value that specifies the schedule access. The number of octets in the field may vary, it is always the last octet which should be used.
     This 8- bit field correlates to the 7 schedules. (See CSOS Certificate and CRL Profile (PDF) 3.3.4) Bit 0: Schedule 1 Bit 1: Schedule 2 Bit 2: Schedule 2n Bit 3: Schedule 3 Bit 4: Schedule 3n Bit 5: Schedule 4 Bit 6: Schedule 5 Bit 7: Not Used In the provided screenshot, the “03 02 01” does not indicate access to schedules 3, 2, and 1. Instead, the “5e” maps to schedule access. In Hex to binary, “5” maps to “0101” and “e” maps to “1110”. Therefore, the 8 bit field for this certificate is “01011110”. This certificate would have access to all schedules except 1 and 2n.
    Validation The order schedules must be compared to the certificate schedules. If the order contains any schedules not approved within the certificate schedules, validation fails.
    Audit Process A certificate not authorized to purchase drugs within the test order should fail validation.

    Audit Case 7

    These audit cases pertain to authorization related to the CSOS application and the signing certificate. Access to the application must require a login, and in-memory retainment of the certificate and certificate password must be tightly controlled.
    Audit Case 7.1 A user must login with a username and password into the CSOS application used to create orders containing controlled substances. Creation of these orders are not allowed in applications open to public access. Also, users in the system must be able to be invalidated.
    Validation Standard username/password (or biometric) authentication must be implemented on the application.
    Audit Process

    • A new user to the system is created
    • Login is successful for the new user
    • An order is created and signed by the new user
    • The user is logged out
    • Access to the application is revoked (via admin or through database changes)
    • Login is unsuccessful

    Audit Case 7.2 Separate from application login, a CSOS application is allowed to re-use a user’s certificate for 10 minutes after the user provides certificate credentials. This could be handled in a variety of system architectures. The following lists some, others may also be valid.

    • An individual has a unique login to the system. A single certificate is associated with the account. Access to the entire application is timed out after 10 minutes of inactivity.
    • After a user logs into the application (with any timeout), the user must provide the password for their certificate (possibly a username as well). After successfully signing an order with these credentials, the user could sign another order without re-authentication for 10 minutes, otherwise they have to re-authenticate the certificate.
    • After a user logs into the application (with any timeout), the user must provide the password for the certificate each time they sign an order. This is the approach in the AtlanticBT solution.

    Validation As noted above, AtlanticBT’s solution required the user to supply the certificate password on every signing attempt. Other approaches may pass this validation as well.
    Audit Process Auditing the solution is a case-by-case basis. For AtlanticBT, showing the certificate password was required on a second order directly after a first order was signed was sufficient.
    Audit Case 7.3 If the password for the user’s certificate (private key) is retained in memory, this must be cleared from memory when a timeout occurs (as in Audit Case 7.2).
    Validation If the password is retained in memory, it must be cleared on timeout.
    Audit Process Not required if password is not retained in memory. Otherwise, code debugging (or some other display mechanism) would be required to verify memory is cleared.

    Audit Cases 8 & 9

    Computers used to sign and validate orders must be synced with the NIST time servers. There is a 5-minute variance allowed. See NIST Internet Time Servers for a list of NIST time servers. Note that “time.nist.gov” is the global address which should be used.
    Validation Any server or computer used in the signing process must be synced with the NIST time servers. For Windows machines, it may enough to set the time server through configuration. (See: How to use Alarms & Clock app “synchronizing with an Internet time server”) Atlantic BT’s solution deployed the web application to AWS EC2 instances. These servers stay in UTC time automatically. Other web servers can be configured to sync explicitly with the time.nist.gov servers. Alternatively, a connection with the NIST time servers can be established at time of signing. Atlantic BT added this as well, and accomplished this by sending a UDP packet, expecting a response, and parsing the response for current date and time. Many methods may achieve the same result. If the difference between the NIST time and the system time is greater than 5 minutes (either ahead or behind) then validation fails.
    Audit Process If time server synchronization is (only) used, auditing involves occasionally changing the system time, and returning later to find the time having synced back to NIST time. If at-signing validation is used, the server time can be changed more than five minutes ahead of the NIST servers, and attempt signing an order. Validation should fail.

    Audit Case 10

    The order file which is being signed must contain a minimum amount of data. This does not have to be verified at time of signing through code, but the audit process involves inspecting the file used in validation.
    Validation The order file must contain: A unique tracking number, made of of 2-digit year, ‘X’, and 6 digit number; supplier’s name, address, and DEA number; purchaser’s DEA number, order date, and ordered substances name & strength (or NDC), quantity, and number of packages.
    Audit Process Auditors will inspect the order file of a newly created order.

    Audit Cases 11 &12

    The DEA requires any information related to orders be archived together in a location identifiable to that specific order.
    Validation Any solution is valid where this information is stored (for a minimum of 3 years). The order file and signature file should be included at a minimum. Any other data generated specific to a signed order should also be archived. For example, if digital files are generated when an order is acknowledged, or upon physical receipt to the purchaser “checking-in” the contents, these should be archived as well.
    Audit Process Auditing the solution is a case-by-case basis. Likely this will involve browsing to the archive location for a newly created order.

    Audit Case 13

    CSOS Development White Paper

    This audit case verifies the certificate used in signing was issued to an individual associated with the purchaser. A pharmacy (as one example) is provided a DEA number for use with purchasing controlled substances. This number is required to be associated with every order the pharmacy makes. When a certificate is issued to an individual, they are signing orders on behalf of the purchaser. Therefore, the DEA number for a pharmacy is part of the metadata for any individuals signing orders for that pharmacy.
    The DEA number is not explicit in the metadata for the certificate. Instead, a SHA-1 (or SHA-256, see below) hash of the purchaser’s DEA number joined with the certificate serial number is. (See CSOS Certificate and CRL Profile (PDF) 3.3.7)
    Validation In order to validate a certificate, the DEA number of purchaser must be known. To validate: 1) Parse the Serial Number from the certificate. This can be done using the certificate’s “subject”. (See screenshot) 2) Concatenate the DEA Number with the Serial Number 3) Create a hash of this string.
    Note: The Public Key Infrastructure Analysis document indicates the hashing algorithm is SHA-1. It is undocumented that the “Signature algorithm” field of the certificate indicates whether a SHA-1 or SHA-256 algorithm should be used. The screenshot shows a certificate using the SHA-256. 4) The metadata field for OID “2.16.840.1.101.3.5.7” contains the hashed value for comparison. (See CSOS Certificate and CRL Profile (PDF) 6.2) 5) Compare the hashes. If they match, validation succeeds.
    Please note that in development, it was determined there was a whitespace offset of the field in the certificate. Documentation of this offset could not be found. For SHA-256 it was a 2 character offset of hex values “0x04” and “0x20”; for SHA-1 it was a 2 character offset of hex values “0x04” and “0x14”.
    Audit Process Signing with a certificate associated with a DEA number different than that of the one used to create the test order should fail validation.

    If we can be of any assistance regarding CSOS, please drop us a line!

  • 4 Questions That Matter for the Mobile App You Want the Most

    Mobile apps are all the rage in the digital marketing world. At this moment, you are most likely rolling your eyes at such an obvious statement. But there’s a good reason apps have only increased in popularity. They help businesses make direct connections with their audience. There are mobile apps that help you do everything. You can manage your social media presence, book a hotel room, or even place an order at a restaurant. But how much do you actually know about mobile apps? Have you been pondering creating an app for your business? Is that the right call?

    What Do We Know About Mobile Users?

    Smartphones and tablets are seemingly everywhere. Since 2011, smartphone ownership has risen 35%. Now, 77% of the American population uses a smartphone. When it comes to apps, the numbers are intense. The average smartphone user has 80 apps downloaded on their phone and accesses at least 40 of them a month.

    It is not too much of a stretch to say that Americans are tightly connected to their smartphones, as users spend about 3.5 hours a day on them. So, it looks like you have a ready-made audience for your mobile app idea. But hold on. There are a few questions you need to ask before you begin building your mobile app.

    4 Critical Questions to Ask Before Building Your First Mobile App

    At Atlantic BT, we’ve had the good fortune of working with clients in a wide variety of fields, helping solve both marketing and IT challenges. Lately, many of our conversations with clients have been focused on the creation of mobile apps. We’ve noticed several recurring questions needed to define the scope of the project. To help you develop the best app possible, and do it quickly and efficiently, we’ve gathered these insights for you.

    1. Should You Build a Mobile App or a Mobile Friendly/Responsive Web Site?

    Sometimes, you don’t need a mobile app. Instead, a mobile friendly version of your site (or a responsive website) will do just fine. Mobile friendly and responsive sites are great options if you simply want to optimize the display of your existing web content on mobile devices. By contrast, mobile apps work best for specific, targeted actions you want your audience to take (i.e. make a reservation at a local restaurant). Mobile apps also take advantage of functions on your phone, such as the GPS, camera, microphone, and more. Knowing what you want your users to accomplish is an important question to answer before you jump into building a mobile app.

    2. Android, iOS, or Both?

    For mobile apps, there are two leading platforms: iOS (Apple) and Android. In today’s mobile environment, you need to develop apps for both platforms. Only developing for iOS is a sure-fire way to tick off your Android audience. Then, you’ll be stuck saying over and over again “Yes, we are currently working on an Android version and hope to release it soon.”

    3. What Will Your Users Do With the App?

    The most successful mobile apps are focused on helping users solve a specific problem. Your app should be no different. Ask yourself what kinds of problems you want to solve for your users. Then build your app to solve that problem. Applications that attempt to do too many things are often not as well received as highly focused apps. A good user experience (UX) process will help you identify the core needs of your mobile app and ensure that those needs are addressed during the building process.

    4. How Will You Update Content in Your Mobile App?

    Mobile app development isn’t a one-time activity. You will need to keep your content up-to-date and make improvements in the app as the platforms grow and change. Build apps on open content management systems using technical frameworks that can adapt over time. Anything less puts you at risk for a dead app as conditions change.

    Get Started with Mobile App Development

    There are many factors to consider when creating a mobile app. At Atlantic BT, we’ve helped companies create innovative and engaging mobile apps that benefited both them and their customers. Our team of consultants, UX strategists, mobile developers and marketers will work with you to help you build the mobile app of your dreams.

  • 3 Reasons to Fulfill the Destiny of Your Website and CRM System

    Does your organization use a Customer Relationship Management (CRM) system? One like Salesforce, for example? If so, you may be wondering whether it’s worth it to integrate that platform with your new website.

    Doing so does add to the technical complexity of your web development project. It also ties you to the software you’re already using. But, let’s assume you don’t have any immediate plans to change to a different CRM. If that’s the case, it’s a good idea to use as many tools as you can on your new website. They can be as intricate as a custom app that integrates contact data with website forms. Or they could be as simple as a plug-in. Whatever elevates your website, you should use.

    You can do some of the same things without coding your website to connect to the CRM. But, it’s smarter to make them work together. Here are three of the biggest reasons why.

    #1 Easily Maintain a Single Contact Management Solution

    Your website can help you gather new customers and contacts. It can also help you to further relationships you already have with those in your network. You could keep them organized in separate lists or databases. Or, you could maintain a single CRM solution.
     
    If you’re going to war, one versus many isn’t an ideal situation (unless you’re Jon Snow). In this case, one solution is all you need and far less work. It’s easier and more cost-effective to maintain. Sure, it’s possible to translate contacts from one platform to another. But, there are better ways to spend your time. Connecting your CRM to your website allows data to move from Point A to Point B with ease. No extra, unnecessary steps involved.

    #2 Better Data Accuracy for Contacts and Customers

    Moving customer contact data between different platforms opens the door to many problems. Beyond draining time and resources, it also invites errors into the process. Phone numbers and email addresses are being typed or converted from one kind of entry to another. Issues can and will arise, no matter how careful you are.
     
    By turning your website and CRM platform into one entity, you make all your data more accurate. That has real-world implications. This can be especially helpful to sales reps or customer service personnel. They often need up-to-date details of prior interactions at their fingertips. Combining your website and CRM platform makes providing that sales tool possible. You can adjust your CRM records in real-time. Therefore, you don’t have to worry about losing conversions or missing time-sensitive opportunities. You can cross that stress right off your list.

    #3 More Revenue for Your Organization

    If you are already using Salesforce or another CRM, it’s because you want to gain revenue and save money. Your website should contribute to these goals rather than pull you away from them.
     
    A strong CRM system will help you with a wide variety of tasks. You’ll be able to identify more sales opportunities. Relationships with existing clients and customers will have room to grow. And you’ll close more business at higher margins. You can use parts of your website as an extension of the CRM software. This allows for better data and stronger reporting. The end result will be more revenue for your company or organization. This makes both your website and your CRM system more valuable. United as one, they are stronger than they would be as independent entities.

    Get More From Your Website and Your CRM

    The website/CRM relationship is a special thing. Getting access to real-time information in a more usable format is the real beauty of it all. Isn’t that what good web development is all about? Of course it is. Are you looking to make your organization more efficient, online and off? Contact the web design and programming team at Atlantic BT today. See how we can help.

     

  • What You Need to Know About the 5 Phases of Software Development

    Most clients think that web software development projects go through three phases. It begins with an idea, the work takes place, and then it’s complete. That’s it, all done, winner winner chicken dinner. Those of us in the industry, though, know that isn’t even close. There are a few distinct steps involved in taking an idea for an app or a website and turning it into a reality.
     
    If you’re considering working with a team of programmers, this blog is for you. You should be aware of how these different parts of the project follow one another. Then you’ll know what to expect after you’ve signed on the dotted line. Being on the same page as your team can lead to productive collaboration and confidence.
     
    Here they are. The five phases of web software development, in order.

    #1 Discovery

    The discovery phase is an in-depth, crucial first step towards the success of your project. During this phase, your programming team will learn about your vision, inside and out. They’ll gather all the details involved with the app or software you aim to create. Every piece of the puzzle matters while they prepare to put it all together.
     
    At the end of the discovery phase, the team will look into the past. They’ll want to know what you’ve been doing, who you are, and what inspires you. They will ask questions about your organization and its members and customers. Other questions will cover your long-term goals and who your competitors are. (They’ll be sure to take a look at what those guys are doing, too.) Learning about these details takes time and attention. But it’s worth it. It will pave the way to an actionable software development strategy.

    #2 Design

    During the design phase, the visual components of your software will begin to take shape. Your development partner will start putting together mock-ups, flowcharts, and other tools. These will all help you to start to see and understand the interface of your software. They’ll also get to work outlining the specific features and functions of your app. By the time the project is complete, you’ll have a firm grasp on everything. You’ll know exactly what your web software will do and have a good idea of how it will look to users.
     
    This is also one of the most creative parts of software development. Anything is possible at the very beginning. Finding the right balance between the fantastical and the rational is the sweet spot. That’s where your project can find its footing and be able to stand out. The right programming team will include you every step of the way.

    #3 Development

    Now that your project has moved into development, it’s time for your hired programmers to get to work. They’ll create and dig through thousands of lines of software code to reach your shared goals. It will be important to them to ensure that you get exactly what you asked for. The resulting piece of software will be efficient and stable. It will also be compatible with many different systems and platforms.
     
    You might not hear from your programming team very often during development. Don’t worry. You can put trust in the right team to do what they need to, without having to look over their shoulders. This is the stage where the real magic happens. If the communication has been solid during the first two phases, then this phase should be a smooth ride.

    #4 Deployment

    Deployment is all about putting your custom web software to use. It’s ready to make its big debut! Your hard work and efforts have culminated into a project you can be proud of. After putting your software on the web, you can finally see how others respond to your new service. There it is, now able to bring enjoyment to your organization and its customers or users.
     
    But wait! The job isn’t done yet. After releasing your software, a good programming team won’t disappear. They will keep track of the sites performance to ensure everything works as expected. Does the software hold up under the weight of increased usage? If so, then you’re doing something right. Has it created any openings for hackers? If your security is strong, then you have a product that is trustworthy. You can count on your new project to provide great service and peace of mind for the long haul.

    #5 Delight

    Your web software idea has become something useful. You should be very pleased and proud of how far you’ve come. Now it’s time to enjoy your success. You can also begin to think about future adjustments and improvements. After all, time in the tech world moves fast. You’ll want your software to stay up to date so you don’t have to go back to the drawing board over and over and over again. It’s not unusual for a finished piece of software to find new uses that would make it even better.
     
    The most important thing that often gets forgotten is the joy of the process. Such projects create hassle, stress, and pressure by nature. It’s unavoidable. But despite this, a great software project can be, and usually is, a lot of fun. Enjoy it. Be creative. Take risks. Opportunities like this don’t come by often. You’ve also made the lives of your customers and co-workers easier. What could be better? Be sure to take it all in.

    Want to Do More on the Web?

    Web software development is all about adding new features and functionality to your website. That could translate to increased sales, data automation, or just fewer hassles in your day. To learn more about custom programming and what it can mean for your company or organization, contact the experienced team at Atlantic BT in North Carolina today.

  • Who is the Winner of the Great Content Delivery Network Race?

    The Internet has more than its share of misconceptions and half-truths. However, one of the most significant mistakes is the belief that bandwidth speed alone determines how fast a webpage will load. The truth is more complicated—your website’s load time depends on user bandwidth and the latency of your server.

    You can’t control the quality of your user’s Internet connection. However, there is a proven way to improve the latency of your server by using a Content Delivery Network (CDN). CDNs support your site by storing and caching your content (such as images, CSS, videos, and the like) and serving this content from an EDGE location. The result? Your webpage and all its content loads faster and more reliably.

    This leads to the natural question: which CDN delivers the right combination of value, reliability and performance? To learn the answer, I designed and conducted a series of tests measuring the speed and performance of four CDNs: S3, CloudFront, Fastly, and section.io.

    How I Tested These CDNs

    I created my test to simulate a typical loading task for a website facing low to modest traffic. Using an S3 server, I pushed a 100kb file and tested how many transactions the CDN could handle over a period of 90 seconds with 100 concurrent connections on a single 300mb/second link; I also measured the CDN’s transfer rate and response time.

    The table below reveals my test results, but first, a few qualifications:

    • I chose S3 as the test server because of my experience with S3 as well as S3’s support from Amazon Web Services.
    • I chose these four CDNs because of their similar price point and my familiarity with them.
    • There was no “warming” of the cache by throwing a preliminary file at it to scale the cache upward. This allowed the test to better simulate a site with modest traffic experiencing a sudden rush of visitors.
    • My test did not include comparisons between the different CDNs’ features, such as the ability to invalidate a CSS file or security capabilities.

    CDN Performance Results and Observations

    S3

    CloudFront

    Fastly

    section.io
    Transactions

    7533 hits

    		 12456 hits 12131 hits

    12284 hits
    Availability

    100%

    		 99.14% 99.34%

    99.51%
    Elapsed Time

    90.03 sec.

    		 89.95 sec 89.81 sec

    89.47
    Data Transferred

    735.64 MB

    		 1216.41 MB 1184.67 MB

    1199.61 MB
    Response Time

    0.95 sec

    		 0.33 sec 0.37 sec

    0.39 sec
    Transaction Rate

    83.67 trans/sec.

    		 138.48 trans/sec 135.07 trans/sec

    137.3 trans/sec
    Throughput

    8.17 MB/sec

    		 13.52 MB/sec 13.19 MB/sec

    13.41 MB/sec
    Concurrency

    79.1

    		 45.05 49.74

    52.9
    Successful Transactions

    7533

    		 12456 12131

    12284
    Failed Transactions

    0

    		 108 80

    60
    Longest Transactions

    9.04

    		 31.15 31.21

    31.27
    Shortest Transactions

    0.12

    		 0.05 0.1

    0.17

    Amazon CloudFront emerged as the clear frontrunner, leading the pack in transactions processed, data transferred, response time, and speed. CloudFront also led the way in failed transactions, though the 108 failures represent less than 1% of transactions attempted.

    That said, these results represent only one test in one set of circumstances. It’s important to try out different CDNs for yourself to find the combination of performance, features, and price that best fits your needs. If you have specific questions regarding CDNs or Amazon Cloud Services, our development team is here for you. 

  • 4 Need to Know Rules for Supporting and Loving Your Mobile Apps

    Communication technology continues to change and grow at a faster and faster rate. It has been 11 years since the original iPhone made its entrance, ushering in the age of the smartphone. Today, between smartphones, tablets, and smart watches, these tiny computers are everywhere.When it comes to maintaining mobile apps as they age, there are 4 critical rules you need to follow.

    Are Your Mobile Apps Up-To-Date?

    TIP:
    Developers get early access to new features, and can give you a heads up on what changes are on the way.

    When your mobile app was first built, it was on a platform that most likely doesn’t work like the ones used today. The capabilities and features of the mobile platform were very different than now. The most dominant players in the mobile market are Google and Apple. They release software updates like clockwork. Apple releases major updates each year. Google releases updates roughly every six months. In other words, if you haven’t updated your mobile app in the past year, it’s likely that users can see its age.

    We, as consumers, look forward to the features these new platforms will offer. When those changes take place, it’s a good time to review what your mobile app needs to stay up to date.

    Four Rules for Maintaining Your Mobile Apps as They Age

    1. Make Sure it Doesn’t Break

    The world of mobile apps is very different from the real world we live and work in. In the real world, the laws of the universe have been around since the beginning of time. We expect them to continue unchanged. In the world of mobile apps, laws are changing at the whim of the company that develops the platform. Imagine if there were a law of physics that determined that all doors must open a certain way. One day, you learn that if you don’t change your doors to open a different way, they might stop working. Sure enough, a week later all unchanged doors are stuck, closed, and unusable.

    TIP:
    Update your apps frequently to ensure they continue to work on new devices.

    As crazy as it sounds, this is the way the mobile apps industry works. Google and Apple will decide to change a feature in an upcoming software release. Then they will tell developers to stop doing something they’ve been doing. It’s on them, now, to make an immediate switch. Finally, if the switch doesn’t happen, Google and Apple will let the feature break. This has happened time and time again.

    By updating your apps frequently, the developers can make sure to heed the warnings of the companies that control their universe. Keeping the apps within the guidelines of each platform ensures that you can always make small updates when you need to. Then, the application will continue to function when new devices are released.

    2. Look Like You Care

    When companies make updates to their mobile platform, they often change more than just the functionality. Even if your app survives the change in features, it will still look like the era that it was designed for.

    No matter the functionality, an app that does not update the visual and navigational structure to match the current generation of the mobile OS will feel like it’s outdated. Often, these are relatively simple changes, updating icons and design elements, and can be done incrementally as each new version is released. Be cautious about letting the design get too old, however, or you may find that it will take more work than you expect to update it to modern standards.

    3. Show Your Users You Care

    “…a mobile app more than anything else is there for the users.”

    Even if your mobile app continues to function as expected, and even if you believe your design still works, users expect updates. That’s part of what keeps them using your app. By keeping your app updated with new features, however small, and embracing the design language of your target platform, you will let your users know that you care.

    When it comes right down to it, a mobile app, more than anything else, is there for the users. Without them, you don’t have an install base. When you push out an update you let them know that you haven’t forgotten them. They know that they can continue to rely on your app as they get new devices with new operating systems. Any data stored in the app that they access on a regular basis will continue to be available to them. Having the confidence of your users means less uninstalls, more market penetration, and a better reputation.

    4. Create a Culture of Continuous Improvement

    TIP:
    Maintaining your apps well is more cost effective in the long run and improves your ROI.

    Compared to the cost of releasing a new app, or of letting your existing app stagnate to the point where a new one needs to be built to accommodate a backlog of features, simple maintenance is cheaper and has a higher ROI. Determining how to implement a continuous update schedule, though, can be daunting.

    The mobile ecosystem is one of the fastest changing in the technology field. It is a field of fierce competition, and it’s always evolving. Once you acknowledge that it is time to update your app, it can still be difficult knowing where to begin. In this case, though, you don’t need to begin, only to continue.

    “…most developers don’t just create mobile apps for their platform of choice, they are also some of the most dedicated users.”

    Let your developers know up-front that you want to keep your app fresh and update it frequently. It will change their mentality when they develop it to make sure they won’t mind working on it in the future. Trust them to lead you in the right direction. Remember that most developers don’t just create mobile apps for their platform of choice, they are also some of the most dedicated users.

    When new versions of mobile operating systems that you support are released, ask your developers for a list of highlights that affect your mobile app. Very often, the requirements for the update write themselves.

    Want to Know More?

    At Atlantic BT, we monitor the changes that are coming up from the earliest rumors, to the day of release. Our dedicated team of mobile developers and user experience specialists are always ready to help you make your mobile app grow better with age. Contact us to find out how we can help you with your mobile app needs.