0

The company I work for was recently acquired by a much larger company. In conversation with their IT systems group there was some discussion about modifying the existing programs so that they use a 'CORE' library. This 'CORE' library is a replacement for standalone class libraries that we created.

My basic understanding is that the UI (windows client program/console/website) all talk to a central core that is web-service based.

Are there any pitfalls to this setup?
My main concern would be in read-write intensive applications that the CORE would not be as fast as a program running all the libraries directly (in the same install path).

Note: We primarily run Windows servers with .NET applications.

Improve this question
2
  • 3
    I don't understand your question. Not everything has to have a name; describe the problem you're trying to solve, instead of attempting to put a label on it. Commented Jun 10, 2015 at 18:18
  • All .NET applications are based on a central CORE library. It's even part of the name: MSCORLIB. ;) Commented Jun 10, 2015 at 18:19

2 Answers 2

Reset to default
1

Sure, this sort of Software as a Service stuff has existed for quite some time now.

Are there any pitfalls to this setup?

Yeah, non-functional internet makes it hard for web services to work without some sort of local caching layer. The latency you talk about can be a concern. It can be harder to test your application depending on how it is designed. And depending on how the library is designed, it can cause issues since any change there impacts all clients, either breaking them or slowing changes to the core libraries.

But none of that matters.

For a large company, they likely have handfuls to hundreds of commercial software applications, it is enormously costly to keep developing and maintaining the same bits of code (authentication, authorization, billing, logging, technical support, internationalization frameworks, etc) and hardware to support that code over and over again. Oh, and it helps speed development since pretty much every large company has to support multiple platforms (web, mobile, desktop).

So while it might inconvenience your customers with shoddy internet connections, it will not make up for the literally millions of dollars the company saved by consolidating the common code.

Improve this answer
3
  • the applications are primarily internally facing so a bad internet connection is less of a concern. Thanks for the insights. Commented Jun 10, 2015 at 19:55
  • "the literally millions of dollars the company saved by consolidating the common code" - honestly, this is extremely debatable. Forcing lots of different teams to use the same in-house core libraries (and so coupling teams and products which have nothing else in common) can produce costs which are much higher than the costs saved. I know what I am talking about, I once worked in five-years lasting project which shipwrecked for exactly that reason. Commented Jun 10, 2015 at 19:59
  • @DocBrown - quite true. I could argue that a single company's software products should be fairly similar, or else they shouldn't be part of the same company... but that's fantasyland. My current company at least does have many similar products due to acquisitions, so it makes sense there. Perhaps less so elsewhere, even if they always think they'll save piles of cash. Commented Jun 10, 2015 at 20:06
1

The pitfalls range from Nothing to Everything, with your real-world results lying somewhere in between.

Standard libraries are used everywhere. For example, we have the C++ standard library that almost all C++ programs are based off of to some degree. Even this standard library changes depending on your compiler, in that the standard library that ships with GCC is not the same as what ships with Visual Studio. Additionally, programs targeting the .NET platform use mscorlib in the same fashion.

We trust these core libraries implicitly because they are written by large teams of very brilliant people, and hope that they run as well as we'd like. However that doesn't prevent someone from writing their own implementation of mscorelib (I'm looking at you, Mono) which they then base their own applications on. Quite simply, there are things that Mono does extremely poorly compared to the Microsoft library that most .NET applications are compiled against. Does that mean that it will break your application? It depends.

Now it doesn't sound like this is the same kind of core library that you're concerned about, but the same concerns apply. If the library is written very well, it's certainly possible to get new functionality and performance boosts. However if it is written very poorly, your application could perform extremely poorly or straight-up break.

Broadly speaking, it depends on where this CORE service is running. For example, a single server running the core functionality is probably a poor replacement to each individual computer running that same functionality. However that may be a trade-off that gains you various benefits, and so it's not black and white.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.