What is our primary use case?
We work as developers and create interfaces. We're doing both interactive interfacing with other applications and enterprise applications. We also do some of the middleware.
How has it helped my organization?
Both WebLogic and WebSphere are only as good as the people making the general design work and the programmers doing the code and the job needed. WebLogic is a good framework to work on. I've been in computers for over thirty years, so compared to what we were doing back in the day, it has an ease of use that we never dreamed about years ago.
As far as being able to go from business logical processes, user stories, or requirements, into actual working code that connects the different data streams, databases, and data lakes, it works well. We can connect our data logically into a working application solving problems much more easily.
WebLogic's and WebSphere's functionality depends on what you use them for. If you come out of an Oracle house, you like WebLogic, and you will like Web Sphere if you come out of an IBM house. There are significant differences except for some of the commonalities of code you would be pulling from based on legacy-type things.
What is most valuable?
In the newer system, reconfigurability and the fact that it is easy to configure, make it very valuable. It is a double-edged sword. For a business user, this is massive because the configuration basics are a square one type of thing.
The fact that we're now working in more Agile scenarios is good. What I've been discovering over the last five years, is that a lot of people who have never known anything except for Agile do not understand the principles that are a part of it, and make some very significant decisions early on. To solve that problem, they may have to build a more extensive solution six months later. Then, they will have to look at that code in a much more overall sense. They'll have to build until they hit their head on the fact that they didn't scale it right or didn't consider it a part of the hierarchy in the business.
Somebody has to be looking at the overall architecture and make sure that the developer is not pushing themselves into a corner with their code or limiting their scalability and have to retest it to make sure that they can move forward at a particular part.
The configuration piece and the fact that you can do the updates are huge. Configuration and updates go hand in hand.
What needs improvement?
I've had issues with some of the tracking features tracking and have had to go back to several generations of code to fix problems where things were touched.
For how long have I used the solution?
I have been using the solution for two years.
What do I think about the stability of the solution?
What do I think about the scalability of the solution?
It is a scalable solution. They're fine for larger companies with huge datasets and lots of moving parts because that's what they're built for. But if you are trying to work on it, there are things you could use for smaller companies.
It scales fine. Though there's a lower limit of scale that doesn't make sense to go down to. They may be getting a small business product line I have not seen.
How are customer service and support?
Oracle's tech support team is good. Oracle's tech support gets grouped all together. The best way to deal with CentOS support is to have a dedicated point of contact. You should put your ticket in and then contact the point of contact to get things expedited to the level it needs to be.
How was the initial setup?
Every setup has hiccups, but compared to some of the setups I've done historically, it's fairly straightforward. This, however, depends on the person setting it up. That person has to work diligently to make sure they lay out the priorities of the work in order to get the architecture appropriately done.
If you have a project manager that facilitates and listens to where there's a disconnect between what the business is asking for and what the technical people are building, then you're okay. If you use a hammer and driving nails, it works great. If you drop it on your big toe, it won't work great, and the reason for this has nothing to do with the tool. It has to do with the person that's building it. As a toolset, it's fine, but it is still quirky in places. But every application toolset has some strangeness to it.
The solution was deployed in three months and it took a year to be fully set up for use. Twelve to eighteen people worked on both the customer side and vendor side.
What about the implementation team?
The integration was done by an in-house team but a tier-three partner was also there to fix any issues during the deployment process.
What other advice do I have?
I rate the overall solution an eight out of ten.
