devopsy.kinsta.cloud

Tag: enterprise apps

  • Looking Back on 20 Years of Enterprise Java

    Looking Back on 20 Years of Enterprise Java

    It is hard to believe, but enterprise Java has existed as we know it for more than 20 years. In December of 1999, the Java 2 Platform, Enterprise Edition (formerly J2EE, now called Java EE or Jakarta EE) was introduced.

    J2EE built on the “write once, run anywhere” mentality of the Java programming language, but made it enterprise-ready by extending the neutrality and portability with specifications that are better suited to build large-scale applications. It also built on years of work on distributed systems, such as the Common Object Request Broker Architecture (CORBA) and the Distributed Computing Environment (DCE).

    Since its birth in 1999, J2EE has played a powerful role in shaping enterprise applications as we know them today. This article will take a look back at the influential programming platform and what is next.

    First, for context, it’s important to note that the enterprise Java platform is not the same thing as the Java programming language, though they are related. Java, the object-oriented programming language, was started as a project called Oak in 1991 by James Gosling and some of his colleagues at Sun Microsystems. The language is coming up on its 25th anniversary, and is important to note for the history of J2EE. The original goals of Java were to create a language that had a familiar notation (drawing parallels to C/C++) but that had greater uniformity and simplicity. Java was also intended to be assembled as a byte code and then run using a Java Virtual Machine (JVM).

    Java wasn’t publicly released until about four years later, in 1995, from Sun. This came at a pivotal time for the world as we know it: the World Wide Web was rising in popularity, and Netscape announced that it would include support for Java in its web browser. Four years later in 1999, when J2EE was released, the industry was going through yet another critical shift when it came to how the world was using the internet: it was becoming something enterprises were not only thinking about, but realized they needed a strategy for.

    The shift to including Java in the enterprise came naturally because it already had developed a loyal following of developers, both within and outside of Sun. The next few years saw continued innovations in the space, and in 2006, Sun renamed J2EE as Java Enterprise Edition (Java EE). This was the same year that Red Hat acquired JBoss. Later that year, Java was formally open sourced by Sun releasing its core Java technologies under the GNU General Public Licence 2.0 (GPLv2). This was one of the most important steps in Java becoming a collaborative, community driven language.

    One of the other major milestones in Java EE was when Oracle acquired Sun in January of 2010. In the years that followed, the Java EE release cadence slowed considerably. At the same time, the enterprise IT landscape was actively shifting from large, monolithic applications toward lighter and more modular application architectures. Java EE was an enabler of the old way of creating enterprise apps, so it also needed to shift to keep up with the times.

    To meet this need, members of the Java community came together in 2016 to create MicroProfile, now a part of the Eclipse Foundation, which is designed to help optimize enterprise Java for microservices architectures. This shift aligns with the general trend of enterprises moving to smaller and lighter applications and making them cloud native. MicroProfile took into account the needs of the developers while still enabling Java to be used front and center. This played a role in Oracle’s decision to donate Java EE to the Eclipse Foundation in 2017, where innovation around microservices could happen quicker and more efficiently. Java EE has since been renamed to Jakarta EE and has a robust community behind it to support the development of even more innovations in enterprise Java.

    In fact, Java has become such a staple in the creation of enterprise apps that there are now projects and frameworks popping up designed to better support it, such as Quarkus, which aims to help Java developers use enterprise Java for new workloads that take advantage of things like containers and serverless. The Quarkus project aims to give enterprise Java a better cloud-native future.

    Enterprise Java has had a long history, bringing with it many innovations and new ways of thinking and working. I am excited to see what the next 20 years (and beyond) hold.

    — Mark Little

  • DevOps Q&A: Datalink’s Dennis Vickers on MobileApps

    DevOps Q&A: Datalink’s Dennis Vickers on MobileApps

    Companies are custom-building mobile enterprise applications to enhance employee productivity on smartphones. devopsy.kinsta.cloud recently spoke with Dennis Vickers, director of Software Solutions at data center services and solutions provider Datalink about this trend and where DevOps fits in to the process.

    devopsy.kinsta.cloud: Why does applying smartphones to business initiatives require so much additional custom-built software?

    Vickers: Companies have developed and designed legacy software to group things that need to get done together into applications. With mobile application development the focus is more granular in terms of functionality. It’s not that the applications that we designed for the legacy environment don’t fit on the smaller screen, though they don’t. It’s really that the whole concept of having a group of functionalities in a single application doesn’t really work in a mobile environment. You need to rethink the way that not only your applications work but really the way that you do work. You need to think more in terms of granular work than accumulation of work.

    In finance, for example, you might have an application that combines accounts receivable, accounts payable, even expense management. You would have an application that would have all of that functionality in it. For mobile apps, what would make sense is to break out the expense management part of that and make that a mobile app that allows users to be able to use their smartphones to actually capture expenses as they’re incurred, as opposed to having to save a receipt or remember what your expenses were and then go back to an application and fill that in later at the office.

    devopsy.kinsta.cloud: How do you apply DevOps development approaches to provide usability on mobile devices for the most needed features and functions of in-house applications?

    Vickers: Mobile applications tend to be single functions focused on getting something done. Users are much less tolerant of anomalies in the software, whether that anomaly is a bug, a poor user interface or anything that is undesirable about the application. They’re not nearly as willing to look for workarounds with a mobile app as they are with legacy applications.

    You have to have a continuous delivery approach with mobile applications because the time frame between deliveries has to be accelerated. You have to automate that process. We’ve made good use of some of the automation tools, specifically Puppet, around doing continuous delivery. We use tools for source control and QA (quality assurance). Some type of automated delivery process is critical because the turn time for release has to be shortened. There’s just not a willingness for users to wait long periods between releases.

    devopsy.kinsta.cloud: Can you discuss the custom-built software project where you developed a custom equipment maintenance app that feeds into the customer’s proprietary maintenance application?

    Vickers: We developed that for an aerospace company that had a requirement to provide field service for one of the Department of Defense systems. They had to be able to maintain large pieces of equipment. We had to build an application that enabled them to be at the equipment and do the data collection that they needed at that time. It walked them through the data collection process right then.

    Before that, they had a paper process where they would print out instructions, go out and write down the information that they needed to collect, and then go back and enter that into an application. This allowed them to be able to do that closer to the actual event, which cut transcription errors and data collection errors and made the whole process much more efficient. That was an extension of a legacy app that added quite a bit of value.

    devopsy.kinsta.cloud: For that Department of Defense project, were there particular development tools or approaches in DevOps for the software?

    Vickers: We used an agile methodology where we iteratively released the software and did test and review and then essentially layered the application. We provide a layering process as we build and add features to the application. We delivered to the customer through an automated process using Chef. We use Jenkins to do some release management, but we often revert back to Chef or Puppet.

    What we haven’t done a lot of yet, which I think is important and I see growing in the mobile platform, is monitoring. I think that monitoring is an important part of DevOps. I haven’t seen that move into the mobile environment nearly as much as I think it needs to. I think it will happen in the short term. I think there’s some good monitoring tools out there that are coming online or that are maturing and are going to be adopted for mobile app dev.

    devopsy.kinsta.cloud: There was another project where you custom-built a jobs app that enables union members to apply for posted jobs without going into the union hall.

    Vickers: We developed a mobile app so union members can review jobs that are available and request the job through the app. They can receive job assignments and electronic tickets to go out and do that job. It saves traveling down to the union hall on a regular basis and makes the whole process much more efficient.

    The only difference in that project is that we needed to integrate with the back end through an API. The tool we used to help us interface with that API and manage that API integration was Postman. We use it for testing, managing and documenting APIs we build or work with.

  • 4 Tech Imperatives in 2016 to Prepare for Tomorrow

    4 Tech Imperatives in 2016 to Prepare for Tomorrow

    Around the start of every new year come a bevy of predictions about what’s coming (or what someone, or some vendor, or some analyst hopes is coming) in the year ahead. Rather than do that, based on recent conversations with many CIOs, I’ve collected what I think are imperative to-do’s for CIOs and IT leaders to ensure their enterprises can innovate in the years ahead.

    If you don’t already have these in your crosshairs, here are four tech imperatives for 2016:

    Action Item 1: While IoT gets the buzz, groom those mobile app backlogs
    The world has gone mobile. That’s no secret. Mobile analytics firm Flurry found that business productivity apps grew 125 percent in 2015, because most every employee today is armed with a mobile device and more comfortable than ever working on mobile devices. And mobile enterprise investments will continue.

    Currently, however, most enterprises still have considerable mobile backlogs. In the year ahead, it’s imperative they address those backlogs. This investment in mobile apps will continue, so enterprises must clear through the clutter and groom their mobile app backlogs. This year you’ll hear more and more about the Internet of Things, or IoT. (I know, I know, how can we expect to hear more about IoT in ’16 than we did in ’15? Trust me, we will.) Companies first must focus on enterprise and productivity-enhancing apps, while planning and preparing systems and plans for the expansion to IoT.

    In the next few years, IoT will include access to wearables and their data, enterprise office equipment, office buildings, cars and virtually anything else that can be tethered to the Internet. But, for now, the focus for most enterprises must be on clearing their mobile app backlog and grooming their mobile app pipelines, and then setting the stage for the architecture that will be required to support their eventual IoT efforts.

    Action Item 2: Get a tight focus on micromoments
    These days, employees are making every second of the business day count, even when they’re away from their desk. Most employees aren’t sitting, working in front of computer monitors; today, most everyone is on the move and spending more time working on small-screen tablets and smartphones. This has changed how we interact with each other—and our applications.

    Today, workers have short exchanges in text or on social media, short discussions on the phone, and short interactions with their apps. Rather than settling in and computing at a desktop PC, we are computing on our mobile devices while we walk office to office, or are waiting in a conference room for a meeting to start. We are computing, more than ever, in “micromoments.” Guiding developers to develop strategically for mobile is still an imperative for CIOs this year.

    What do I mean? Development teams must ensure their apps are built so users can engage in the context of their moment, based on their location, the task they are undertaking or perhaps the time of the day. Thus, apps must be developed so that data can be entered quickly and easily and consumed readily. And the micromoments app experience must be congruent with those on notebooks and tablets, when people typically are settling in for longer stretches of work and concentration.

    Action Item 3: If enterprises haven’t already, they need to develop their IoT brokers and management platform strategy
    All of those IoT devices we mentioned above will need to be managed. This will require cloud-based platforms that will:

    • look at the data,
    • protect the traffic from being attacked,
    • accept legitimate traffic,
    • dispatch it to where it needs to go,
    • save the appropriate data for long-term analytics,
    • send other data for real-time analytics and response, and
    • enforce security and privacy policies.

    Managing the security, storage and traffic will be a strategic effort in the years ahead, and the groundwork needs to be set sooner rather than later.

    This year is the time to build the strategy for your enterprise’s IoT platform strategy, so the IoT data can be managed properly and management can scale as the use of IoT grows. Think this won’t apply to you? Think again. Gartner predicts that there will be more than 25 billion IoT devices by 2020, up from 4.9 billion today—and a good portion of them will be enterprise IoT devices.

    Action Item 4: Create the data-driven culture
    Big data analytics has touched nearly every aspect of business, from health care, with data-driven medicine saving hundreds of millions annually, to electric utilities managing the grid more intelligently, to helping marketing teams understand and pinpoint their target audiences with more intelligence and precision than ever before possible.

    What’s often forgotten about big data analytics is that success here is about much more than databases, storage, dashboards and data scientists. It’s as much about creating a data-driven culture in which decision-makers in the organization are motivated to make the most of the data and analytics to move the organization forward in the best way possible. Strategically, CIOs want to create this culture, make as much data as possible available to employees, and deliver the data to them in the context of their roles. They want to develop platforms that democratize the data to as many people as possible so they can seek the insight they need.

    Enterprises today already have a lot of the critical data in their software, ERP systems, employees and customers. In the years ahead, IoT devices will create additional tsunamis of data to be analyzed and acted upon for strategic advantage in the earlier years and to simply maintain the status quo in the years beyond. That’s why it’s so important to get this on the strategic radar today.