integration and implementation of technology-focused business solutions

Continued support for Oracle Forms and Reports

February 3rd, 2018

Oracle has always been known as a database company, but there came a point in time where they recognized a need to provide developers with additional tools for developing software that would easily integrate with the Oracle database. Thus, Oracle Forms and Oracle Reports came into existence.

Oracle Forms allowed developers to create data entry forms with fields that easily map to the database. Oracle Reports were also pretty straightforward with reports based on SQL select statements like most reporting systems. At the time they were released in the late ’80s, the formatting was pretty limited since they were running on screens with a black background and green font.

When initially launched, the systems were installed on each individual computer. It took time and effort to complete each install, and if someone got a new device, it had to be installed again. All of the heavy lifting was done by the individual computer, and the applications took up a significant amount of memory.

Over time, Oracle realized that things were changing and the applications needed to be web-based. They made that switch in the mid-to-late ’90s. Organizations no longer had to install the system on each computer, but rather simply accessed it by clicking on a link. The computer would bring up a Java application while using it, and once finished, the computer would let go of all those resources.

Despite some improvements over time, Oracle Forms and Reports are technically considered legacy applications at this point. Oracle has clearly stated that the current version of Reports is the terminal version, which means they will no longer invest in improvements to the system. While Oracle Forms hasn’t been designated a terminal version, there are better alternatives available today.

If building a new system, we would recommend choosing different tools to accomplish both forms and reports. But what about those companies that have a significant investment in those systems currently?

For some companies, it makes sense to switch to an entirely new system and migrate all of the data. Others may not be willing or able to take on such a transition. We had one client who had built an in-house ERP (enterprise resource planning) package over the course of about 15 years using Oracle Forms and Reports. They had hundreds of menu objects, about 1,200 forms that totaled nearly 5,000 pages, and 130 reports. The cost to fully convert was close to $1 million, and they couldn’t afford it, so we continue to support their existing systems.

As older employees retire, many companies are finding themselves without the internal knowledge to support complex systems built with Oracle Forms or Reports. It can be challenging to find an IT company that can support legacy Oracle systems, but it’s one of the many services we offer. If you are using Oracle Forms or Reports and need support to keep your systems fully functioning, contact us today for more information.

Comments: None

Managed services for Oracle Database Appliance

January 16th, 2018

Oracle Database Appliance is a powerful system. It’s pre-built and pre-configured, and it integrates the software, storage, computing, and network resources needed for a continuously available database system. The system is built with redundancies so that it continues working even if one component fails.

The problem with Oracle Database Appliance is that it can be a bit of a behemoth to manage for some organizations. Over the years, we’ve seen two things happen with organizations who use Oracle Database Appliance.

First, staff turnover happens, and the people involved in the initial purchase are gone. The people left at the company to support it weren’t involved in the purchase, and they may not have the skills to manage and maintain it. As new releases and patches occur, there can be some weekend maintenance required, and the company may not have the staff necessary to cover it.

Second, it can be hard to hire a staff person with the right combination of skills to manage Oracle Database Appliance. Since it’s multiple technologies in one system, it doesn’t fit cleanly with one specific job title in IT. Is it the network administrator? Database administrator? System or server administrator? It’s actually all of those positions in one, but most organizations aren’t structured in a way where all of those positions work together on one system.

When it comes to managing Oracle Database Appliance, many companies choose to outsource that support. By outsourcing, the company is guaranteed to have the necessary skills and confidence to maintain the system, and they have someone to handle weekend upgrades and any troubleshooting that’s necessary.

At LSG Solutions, we offer a monthly managed services package for Oracle Database Appliance. We support the database and any patches or upgrades, as well as any hardware issues that may occur through both on-site and off-site support. We work with companies to identify the capabilities of their existing staff and then provide supplemental support to ensure proper management and maintenance of the Oracle Database Appliance system.

If your company uses Oracle Database Appliance and wants to ensure that the systems remains fully functional, contact us today for more information.

Comments: None

The value of integrating kanban and scrum-agile

January 2nd, 2018

In the world of software development, most organizations use the scrum-agile approach or a kanban approach. But it's not unusual to find organizations that wonder if the other way might be better.

That usually happens with organizations that are entrenched in the way they develop software via scrum methodology, and they start to wonder if kanban might be a better approach.

In some cases, a software company will look at the alternate solution and decide to pick and choose some features that can be applied to the process they’ve already built. That’s exactly what we’ve done at LSG. We’ve taken what we consider to be the best of both worlds and combined them into a process that works for us and our clients.

Scrum-agile and kanban aren’t competitors in terms of software methodologies. They’re simply two different ways of doing things, and pieces of each have valuable application in the software development world.

For example, scrum-agile tends to focus on getting things done and marking them off the list. You may end up with a team of developers who are so focused on clearing out their tasks that it’s somewhat like when you clean four rooms in your house by throwing everything into another room. It’s out of sight and out of mind for the people who checked it off their list, but something still needs to be done to finish the job.

Kanban focuses on the importance of looking at the overall flow and the complete picture, not just one task at a time. The kanban approach encourages periodic review of what’s still incomplete and why, and it’s amazing the little reasons something may be incomplete. Brad needs to talk to Sharon who needs to talk to Mike who needs to talk to Lisa. No one really knows if the task if done or not, and before you know it, two months has passed.

Both scrum-agile and kanban are swim-lane oriented and focus on moving things from left to right until complete. But adding kanban helps give a better view of the work in progress and focuses on continuous improvement. It’s not just about “let’s get it done,” but also about, “how can we do it better?” While it may seem like a new approach for some in software development, it’s been proven successful again and again in lean manufacturing.

For software companies that haven’t implemented either approach yet, I recommend going straight to the kanban mindset and implementing that first. Then you can go back and look at scrum to see if there’s anything extra to add from that methodology.

For software companies already using the scrum methodology, adding kanban doesn’t mean scrapping everything you have-it simply means modifying your process and adding the pieces that work best for your organization.

We’ve found an integration of both methodologies to be highly successful for our team at LSG Solutions, and we encourage other software developers to consider integrating them as well.

Comments: None

How Kanban transformed our company

December 19th, 2017

At LSG Solutions, we’re firm believers in the fact that systematic processes lead to more predictable outcomes, and that lessons learned create even more predictability over time. It’s a lesson I learned while working at a manufacturing plant during college. They allocated time for employees to think about process improvement and implement ideas, which had a significant impact on the company over time.

These process improvement strategies, which are frequently used in product engineering and manufacturing, continue to trickle down to the software development process. The software development process isn’t always predictable, but there are still steps you can take to improve the process.

For us, Kanban is less about the tool and more about the philosophy. It’s a way of thinking that embraces the need to think and reflect on projects when they’re complete and identify areas for continual improvement.

There are a lot of great things about Kanban and how it has impacted our company. Here are my top nine.

  1. Creates a more efficient flow of work. Everyone can see the visual layout of tasks and projects.
  2. Allows people to be thinkers. It builds reflection time into each project to ensure that important steps aren't overlooked.
  3. Focuses on implementing manageable change, not dreams. There’s still a place for the dream projects, but projects have to be broken into manageable chunks.
  4. Empowers all levels to lead. If someone notices a bottleneck in the process, they can change it.
  5. Prevents spreading people too thin. If too many things are in progress, there’s not enough time to ensure proper completion.
  6. Encourages open communication. It creates transparency around the issues, especially those that affect efficiency.
  7. Takes assumptions and guess work out of the equation. Instead, it encourages asking questions to seek clarity.
  8. Encourages people to be savvy in the theories of risk, processes, and workflow. Many people are afraid of risk, but it’s necessary in the business world, and it’s easier to manage when you understand it.
  9. Helps make decisions, predict outcomes, and compare to actual results. You can’t improve what you don’t measure, and Kanban helps us measure what we do.

There’s no magic scientific formula for creating a perfect software product, but there are some things you can do to influence the outcomes. At LSG Solutions, Kanban has changed the way we think and approach software development. We have in-house software developers who understand risk, workflow, and processes, which is something that differentiates us in the market.

Comments: None

The importance of finishing what you start

December 5th, 2017

There was a time in the past (and still today at some companies) that software developers and users suffered from shiny object syndrome. Big ideas got tossed around and started, but projects didn’t get finished, or they looked dramatically different than the original idea. Often those projects started with too many requirements or a lack of clarity around the end goal.

The issue of shiny object syndrome sparked many companies to begin using the agile-scrum approach for software development, but it also created a broader awareness of the need to prioritize. By breaking projects into smaller pieces and creating clear priorities for those smaller pieces, it’s easier to set expectations for what can be accomplished in a given period of time.

This approach in my work life carries over to my home life. I frequently tell my kids to finish what they start. I also tell them they shouldn’t start a project unless they believe they can finish it. Those projects might be a grand idea for a Lego build, or any other project they dream up, as their brains are always dreaming up great ideas.

For my kids, there are two things that typically interfere with completing such projects: they get frustrated and decide the project is too hard or they simply get distracted by something else. The same is true in the business world. It’s human nature, and it starts at a young age.

I’ve seen businesses start way too many software application endeavors and then assign one or two developers to each endeavor. Then the projects just go on and on. The organization claims the projects are a top priority, but they never get completed, which frustrates the developers and the company’s leaders.

Whether it’s a business or your child’s Lego project, our human nature is to start too many things and not finish them. Then we end up extremely busy, but highly unproductive because we can’t figure out how to prioritize the work flow. To counteract that, the people involved need the ability to determine the flow of production.

At LSG Solutions, we’ve fully embraced both the agile-scrum approach for software development and the importance of finishing what we start. And we’ve found a great tool to manage it, which we’ll tell you about in our next post.

Comments: None

Why we use an agile-scrum approach for software development

November 21st, 2017

In the IT world, there are many projects that are too large and complex to be successfully managed in one piece with a defined single point of completion. Once the industry realized this in the early 2000s, the process of agile development was born. Agile development is about ongoing delivery and continual improvement of software, rather than that single end point of one large project. It also helps break down large projects into smaller, more manageable steps.

At LSG Solutions, we have been using an agile software development approach for more than a decade. We take a large project and break it into smaller pieces with primary units that last about one month, which are known as a sprint. So instead of running a marathon, we’re running a series of shorter sprints to accomplish the goal.

Every project is different, so the number of sprints will vary. All tasks for all projects are put into a sprint backlog, which means it’s waiting to be assigned and worked into a specific sprint. We’re continually adding things to the sprint backlog and then working them into sprints, which makes it a constant work in progress that stimulates both the mind and the technology. We use a specific software (Atlassian Agile Jira) to manage the assignments and organize them into sprints.

Scrum, which often goes hand-in-hand with agile, is an iterative approach. Each month-long sprint involves a day or two of planning and approximating effort. Each day has a short meeting to discuss progress and impediments. And at the end of each sprint, we reflect on lessons learned.

The scrum approach identifies the people who are actively involved in a task and those who are committed to or accountable for that task. Three specific roles are assigned: scrum master, product owner, and team member. The scrum master runs interference and acts as coach throughout the process. The product owner is the staff person or group who will be using the software system, which means IT doesn’t own the system in this accountability model. And the team members are the developers and subject matter experts who will be working on the project.

Product owners are involved extensively in determining the order that pieces should be worked, or the prioritization of smaller pieces as opposed to working on large pieces with little visibility. They are also in charge of the entire product backlog, although the team is involved in setting expectations as to what can be accomplished in each sprint.

With large pieces broken down into smaller pieces and assigned to different team members, it’s much easier to measure progress on a large project. When we complete estimates each month during sprint planning, we’re estimating those smaller pieces that can be measured along the way.

With each sprint, we have clearly defined goals for delivering increments of software. We use this process because it helps our clients have visibility into the software production process as opposed to waiting and wondering about their project’s status.

Comments: None

Reflecting on the days of pre-agile-scrum software development

November 7th, 2017

Long before agile software development started to mature, LSG leader Alan Sheppard recognized that there were significant challenges in the way things were done. Organizations struggled to create and manage a product when trying to balance the software developers’ approach, the business expectations, and the conservative risk managers’ requirements. Too many people couldn’t see eye to eye on how to approach and address the engineering of a large mission-critical product.

Some software developers had shiny object syndrome and never finished what they started, despite starting many tasks. Other developers could not adapt to the varied skills of their peers.

Some business owners or leaders just wanted it done, regardless of whether or not “done” was feasible. Others in the business world truly never knew what they really wanted done, and the right visionary people were too high up to get involved.

Some wanted every pre-defined feature and/or requirement available plus all sorts of new requirements. Those new requirement requests typically came as a result of developers explaining a perceived bigger, better, cooler way to do something.

In the midst of all these different expectations and approaches, the key end users often worried that the system would no longer be funded after the initial go-live, so everything would have to be rolled into one opportunity. Back then, the mindset of having multiple, ongoing opportunities didn’t exist.

Most expected the design phase to be a one-time start-stop effort, yet parts were moving all over the place during the entire project.

Then there were issues with accountability where stakeholders would blame the software developers if anything went wrong instead of focusing on measuring progress and quality. And if something went wrong, software developers would blame the end users for miscommunication about the requirements.

As the project continued, tensions would rise in the development team due to irrational constraints from a list of hopes and wants that conflicted with hard deadlines and limited funding.

Back in the late ’90s and early 2000s, IT software projects took big hits due to poor poor project management and software development processes. People in the industry learned many extreme lessons, yet some of these same obstacles still have to be addressed today.

LSG has been pro-agile and pro-scrum development since 2007, and we work closely with all of our clients to create clear expectations and efficient implementation of software development projects.

Comments: None

Understanding software estimates based on time

October 17th, 2017

We previously explained that a realistic budget based on a realistic understanding of the product is the best recipe for a realistic estimate.

However, budget is not the only consideration. You also have to consider the time that it will take to complete a project and how your request for proposal can influence time.

Some features require more work to add

You may want that special software feature for your business, but in reality, that feature is step 6 out of 10. Other software functionality needs to be built before the feature you want can be used. More steps mean more time. More time means more money.

This is a big reason why it doesn’t make sense for a software company to quote a block of hours without both the estimator and customer having a complete understanding of the project needs.

In some cases, customers don’t know how much time is involved. That’s why estimating hours for a project is difficult, and why you shouldn’t consider an estimate set in stone.

More people doesn’t equal less time

There’s a myth out there that adding more people on a project will reduce the amount of time it takes to complete. That’s not the case. Typically the issue is not that there aren’t enough people doing the work. The issue is the complexity of the work requested.

Deadlines and timelines don’t always match

The most difficult part of estimating a project is matching our customers’ deadlines with the amount of time that it will take to complete a project.

Sometimes, these deadlines are aligned with time-sensitive needs, but completing the project in its entirety might overrun that deadline.

In these cases, customers must either push out their deadline or be okay with launching software that isn’t fully built out.

It’s important to choose a technology partner that values open dialogue about such projects so both parties know what’s required for successful and timely completion.

Comments: None

How to stay on budget with software upgrades

October 3rd, 2017

Estimating is one of the most difficult parts of our job. There’s natural tendency to treat estimates like promises. And in the software business, there are many reasons why a project might end up more expensive than estimated.

Here are a few things for customers to keep in mind when approaching a major software project. Understanding what features you need, knowing what you can afford, and being open to suggestions from an IT provider can make life a lot easier.

Know what you can afford

The key to getting the software you need and not breaking the bank is to be realistic about your budget.

It’s easy to put down on paper what you’d like to have. But in the software business, where you can’t touch or see what it is that you’re asking for, there’s a tendency to overshoot. Features sound simple enough to add, but each feature adds on cost and time.

Be open to change

Like a custom-built home, each feature that you add costs more money. If you’re flexible enough to know the difference between a must-have and a nice-to-have, you can get the most bang for your buck.

In some cases, features that you thought were necessary might prove too expensive. And in the long run, you may be able to get all that you need without those features. We work with our customers to decide what they need and what they could do without.

It’s important for our customers to be flexible. Otherwise, projects tend to go over budget and take longer to complete.

Don’t set an estimate in stone

Remember that ultimately an estimate is an estimate. Start with a realistic budget, but understand that there’s always a chance work will take longer and cost more than was originally planned.

Comments: None

How a little trust can start a great relationship

September 19th, 2017

Sometimes, a little bit of risk and some trust can be the start of a great business relationship. In this post, I'd like to show you how that concept helped both LSG Solutions and GET Imaging find a solution to an IT problem.

Taking smart risks

Not every deal is a safe bet, and we all know what a bad relationship is like. Knowing your strengths is the key to choosing the right amount of risk.

GET Imaging's system was built with Oracle Application Express, or APEX, which is a pretty standard framework. While we didn't know the full history of the customer's system, we knew that our experience with APEX qualified us for the job. We knew there was a good chance we wouldn't see anything we hadn't seen before in that system, but we didn't know that for sure.

We weren't the only ones taking a risk in this scenario. The client had invested 4,000 to 5,000 man hours in their current APEX system, and they had never worked with an outsourced IT solution before. Trusting someone else with their system was a huge step.

Regardless, they were willing to trust us enough to pay up front for 40 hours of work. If they were happy with the business, we could continue working together.

How we helped GET Imaging in 40 hours

With this project, our primary goal wasn't just fixing a single system. We also wanted to gain enough trust with the client that they'd continue doing business with us.

Using the allotted time, we first focused on gaining a high-level understanding of the APEX system's role in the client's business. Then we drilled down into the system's problematic areas and uncovered some big-picture problems that the client didn't know about.

Being able to identify fixes to these problems built enough trust with the client that they continued doing business with us.

Just enough trust

One of the primary issues we face with clients is that they have trouble trusting vendors. Sometimes, as in this case, it's because they were used to working with somebody in-house. In other cases, it's because they have been burned before by an outsourced vendor, and they don't want to get burned again.

Productive business relationships require just enough trust. GET Imaging trusted us enough to get a feel for how our services fit their business, and that became the foundation of an ongoing business relationship.

Comments: None


501 E. 15th St., Suite 200B
Edmond, OK 73013