Do we create services when we write programs, or are they commodities?
Are we like window-washers in that our programs(actions) provide some services to the users?
OR: are we like carpenters in that our programs(products) are sold and used by their new owners?
Or should this be seen in different aspects: The act of programming being a service, and the resulting program is a product?
The above has a direct impact on the following question: Is it theft or fraud when you copy software that you have no rights to? Theft is the physical removal of an object of value from the possession of another; fraud is representation of a falsehood in such a way that leads to the economic loss of the victim (the representation here being your assumption of right-to-copy).
It also impacts on questions of causal liability: If the program you wrote to crack passwords are used by others to rob a bank: are you an accomplice? If your program is a service then it could be argued that you are; if a commodity then you 'should' be in the clear.
Or: should each program be treated as a unique instance, based purely on the intentions of that program's originator, as to wether it should be treated as a service or commodity? Or should the user's intentions be used?
How does this reflect on the open-source world where many programs are available that seemingly infringe on commercial rights, e.g.: copy-protection and DRM circumventions?
(This impacts us all every time that we write code.)
It's both actually.
Sometime you sell a product which just works. It's a commodity. A notepad program for example is a commodity, you don't go into any relationship with its author. Most small tools fall into this category.
Sometimes you develop a custom application tailored for your specific user, or you integrate an existing product with their legacy applications and adjust it to work for their specific situation. It's definitely a service and you are usually in a long-term relationship with the customer. Most 'big'/expensive programs fall into this category. You could buy MS SharePoint Server license as a commodity but in most scenarios most likely you will also buy a service of someone to make it work for you.
Related
I'm designing a microservice-based architecture for an existing monolithic app. The database has a User table, and then a separate Subscription database storing subscription info for premium, subscribed users.
My initial idea was to do something like User Service <-> Subscription Service <-> Payment Service. But a colleague believes that the subscription service is unnecessary and can just be merged with the User Service. What is the best practice for this?
The problem is analogue with the choosing bounded context boundaries problem in DDD. Choosing bounded context can be done with context mapping: https://www.infoq.com/articles/ddd-contextmapping/ As far as I remember another approach is imagining the organization which does the same job manually what you automate with your services and check what departments it should have. The usual example is a webshop for this where for example security, shopping, storage, invoicing, delivery, support can go in different services. All of them have user and some of them has product, but they watch these things from different viewpoints, e.g. in the shopping context the product is something that you have in the catalogue and what the customers choose to add to their basket, for invoicing it is an item in the order with a certain price at the moment of the ordering, for storage it is something that must be found in the physical world, probably has a container number, for delivery it is part of a package and must be delivered to an address. Many times a lot of properties are just copy-paste with different property names in these bounded contexts and the DRY principle is not met. So if the reason why your colleague wants to merge them is meeting the DRY principle, then it does not matter. If they belong together logically and in a real company a single department would do them, then they can be merged. There is not much detail in your question, but I think I would separate the subscription service too and I guess I would rename the user service to security if all it does is registration and handling logins and authorization. If it contains something else too, then it is better to check the boundaries, maybe some of the properties belong to a different service, maybe there is another service which does not exist yet.
Another practical aspect is scalability. You can wait until certain parts of a single service is used a lot more than other parts and think about splitting because of scalability reasons.
Another analogy is choosing class size in OOP. Some people claim the smaller the better, but everybody is comfortable with different class sizes. Of course there are too small classes and overengineering and too big classes, god objects, but there is a range where the class size is acceptable and it depends on the personal taste or convenience which size you choose. I think for microservices this can happen too, so maybe your colleague is just comfortable with bigger services. If you check the name of the technology the service size should be micro. Those this is relative too, micro compared to what...
In my view a single deployable service should be no bigger than a
bounded context, but no smaller than an aggregate. I would also
suggest that it’s better to start with relatively broad service
boundaries to begin with, refactoring to smaller ones as time goes on.
Perhaps “micro” is a misleading prefix here. These are not necessarily
“small” as in “little”. These are services in the classic SOA mould,
except created with more of an agile mind-set including lightweight
infrastructure, decentralized governance and greater emphasis on
automation. Perhaps it’s these more agile aspects of microservice
design that distinguishes them as opposed to size.
https://www.ben-morris.com/how-big-is-a-microservice/
A Microservice shall be no larger than that which allows a two-pizza
team to release a single complete, appropriately sized user story to
production within a single day.
https://kylegenebrown.medium.com/whats-the-right-size-for-a-microservice-bf1740370d47
Microservice developers can start wherever it “feels right”, and over
time split or merge microservices to improve the architecture.
Although I agree that microservice architectures shouldn’t be carved
in stone and that there should always be the option of changing
microservice decomposition, it’d be nice to have more clarity as to
where a good starting point would be.
Identify critical business transactions that require high performance
and/or solid data integrity and trace those transactions through the
microservices in your architecture. If you see problems, consider
changing microservice boundaries and merging a few microservices
together, as an option.
https://www.pipservices.org/blog/whats-the-right-size-for-a-microservice
Background
We are a B2B company with no in-house developers. We're current outsourcing all our development work to a small software company. They've built their own custom CMS, which we are using.
At the moment, we're in a redesign phase where a new website is being build by this same software company, again tailored to work with their custom build CMS.
At the same time, we are planning to have a webshop, which is going to be built by a different company, a big E-Commerce software company.
What we need
In the end it should be one website, on the same domain. Where content and commerce should go hand in hand. Everything should be seamlessly integrated with each other, for example the search function (they both offer their own search engine), content and products.
Wouldn't it make more sense to let one company build everything instead of two different companies? What are plus or downsides to work with one or two companies in this case? Where could it go wrong?
I'm a bit scared when we work with two partners, that the total cost of ownership is going to rise to the moon. That it will bring a lot of inefficiencies with it and we're hindered when it comes to further scaling.
P.S. I'm not a final decision maker within this company, but I'm looking for input in order to change the current plan (which is working with two partners).
An interesting scenario that you are in here.
Wouldn't it make more sense to let one company build everything instead of two different companies?
Based on your description there is nothing in this that is particularly out of the ordinary. A website for your company with an online shop. There is no good reason why you need two contractors. What I mean here, is that there is no reason why one company cannot provide the expertise to deliver both parts. Adding a second company / contractor will add more complexity to the situation and therefore breaks the generally good rule of keep it simple. (More on this later).
What are plus or downsides to work with one or two companies in this case?
The positive of working with two companies is that you can get experts in the different areas. For example if company A is an expert in one part of the solution and company B is an expert in another you get the combined expertise. However, in this case there doesn't seem to be a need for this.
Where could it go wrong?
This is very much the downside of having two companies working on this. The two companies will need to work together to provide the solution. This is likely to require some management from you (or your company) which you correctly identify the cost of ownership can significantly increase. You run the risk of both of your contractors pointing the finger at each other when things go wrong.
I would strongly recommend at least considering using a single company for the whole project delivering a combined website and online shop.
At our company, we are looking at replacing a number of legacy systems that handle information from our customers into our company. Typical systems allow the user to drop an ftp file somewhere. This file will then be transformed by a number of programs and eventually end up in some kind of database. In total we have +30 different "systems" or applications that does this. And, it is more or less a mess.
We believe we lack a common system to manage these flows: triggered by upload or possible another event, register the data, create some sort of "job" (or process) from it, pass it through the variuos services/transformation programs it needs to go through, provide feedback to the customer, provide information about progress, etc to us, handle failures and so on. Sort of like Jenkins (/Hudson/CruiseControl/similar) but for information transformation jobs, rather than build jobs, and with a job beeing more of a "process instance" of a job, then the job itself (e.g. different data should trigger the job several times, running concurrently).
We are cabable of writing such software ourselves, but surely software as this exists(?) I have been googling around, and found that what we need ma possibly be "job scheduling" software or "business process management" software. However, these are all new domains for us, and I am quite uncertain to as what kind of software would fit our needs. It appears one could invest quite a deal of ressources into this type of software before
So, what I am looking for is pointers to what kind of software or systems that could solve the kind of needs we have. Preferably Open Source, Java based, running in a Java EE container or similar, but really, at this point, almost any pointer/hint will be welcomed :-)
Thanks in advance
P.S. I realise I may be out of scope for Stackexchange, but I have been unable to locate another forum where this kind of question might be answered, so I hope it is OK.
I know of the following products:
Redwood Cronacle (I worked with it 1994-1997 and it still runs). Purchase product. Oracle and C based. Strong in multiple server platforms. Embeddable.
Oracle E-business suite core. Purchase product. Oracle based. Strong for integration with the same ERP system. Weak for multiple server platforms.
Invantive Vision (I developed it :-). Purchase product. Oracle and Java based. Strong in integration with ETL (Pentaho open source). Weak for multiple server platforms. Embeddable.
Quartz Scheduler. Apache license. Java based. Worked with in 2004 or so. Strong focus on embedding.
Hi I don’t know if you will find that solution in open source or Java. It sounds like bespoke or custom software to me. I would advise you to search for a project management software developer with high level of IT and Data warehousing. Ask for bespoke and customized installations with a real time database. I think you will solve your problem with this.
Basically my project is product based.
Once we developed a project and catch the multiple client and deploy the application based on their needs.
But We decided to put the new features and project dependent modules are as component.
Now my application got many number of customer.
Every customer needs a different features based on the component.
But we have centralized component for all client . we move the components additional feature to client specific folder and deploy.
My problem is , I am unable maintain the components features for multiple client.
My component feature code is increased and I am unable to track the client features.
Is there any solution for maintaining the multiple component features for multiple client ?
I've worked for a couple of companies in a similar space - product software but very heavily customised.
Essentially there is a decision the company needs to make - are you a product company (that is you ship broadly the same to every client) or are you a bespoke company. At the moment it sounds like they're between two stools and wanting the economies of being a product company with the ability to meet specific client demands the way a bespoke software company can.
Assuming the company wants to be a product software company, unless there are specific technical reasons why you can't, you need to move to a single code base with the modifications for each customer being handled through customisable options (i.e. flags saying how this particular situation is being handled, whether this feature is available and so on).
These can be set at run time (so they can be changed as the client wants - think options in Word or Excel), or build time (so code is included / excluded when you do the build), but the key things is that every client has to be pulled from the same code base.
But this needs to be agreed with the business as it limits what they can sell - every change they sell has to fit into an overall vision which can be accommodated by the single product.
The alternative is that you're essentially producing bespoke software for each client (that is coded specifically for what they want) but using many common libraries. That's fine and allows you to produce something which is exactly what they want but in the end it is going to be more work and the business needs to understand and cost for that.
We actually do a bit of both - there is a server product which is identical for all clients, and then web and mobile clients which are specific to them (in the case of mobile you can't have lots of dead code on the device - the web stuff is historic and will be moving to a standard product for all clients).
Good luck though, it's a difficult problem with no easy solution.
You are essentially talking about software product lines (SPLs): variations from a common base. Since you already package your features as components, you need a specialized tool to manage such variations.
You can then build a complete custom application based on a configuration that is unique to any given customer. Easier said than done, of course.
A model-driven software development(MDSD) approach can help a lot on this task. One such system that can support this development setup is ABSE, an emerging MDSD approach that among other things, can implement a software product line (info at http://www.abse.info - Disclaimer: I am the ABSE project lead). There is no product yet though. An alpha preview is coming.
Again, I know some companies that, using an MDSD coupled with code generation, have achieved what I understand you want: products that are half pre-packaged, half custom.
I hear a lot about these, but from what I can tell they're no more than highly customised CMS's that allow content to be fed in from third parties such as hotels etc., perhaps with an online booking mechanism.
DMS just seems to be a marketing term for something a developer would be more likely to refer to as a CMS. Is this correct?
Well, wikipedia says:
“Destination Management Systems are systems that consolidate and distribute a comprehensive range of tourism products through a variety of channels and platforms, generally catering for a specific region, and supporting the activities of a destination management organisation within that region. DMS attempt to utilise a customer centric approach in order to manage and market the destination as a holistic entity, typically providing strong destination related information, real-time reservations, destination management tools and paying particular attention to supporting small and independent tourism suppliers.” Frew, A.J. and Horan, P (2007) Destination Website Effectiveness – A Delphi Study-based eMetric Approach, Proceedings of the Hospitality Information Technology Association Conference, HITA 07, Orlando, USA
One thing I really don't think it is, is a "glorified" CMS system (assuming CMS stands for Content Management System!).
Having previously worked in the corporate travel management industry, and helping to develop an "online booking system", I'd like to think I know a little about this.
For the consumer perspective, it's a relatively straightforward process when you think about it. Hotels and Airlines will syndicate their inventory, usually via a mechanism called a GDS (Global Distribution System). There are only really a few of these in the world, and the "big players" are the likes of Sabre, Worldspan, & Amadeus, although some smaller airlines and hotel chains have their own systems (usually run in conjunction with one of the "big" GDS systems!)
For the consumer, you can use an online system to book and manage your holiday (vacation). This may consist of no more than a flight (consisting of two parts - outbound and inbound to/from your destination) and a hotel at a specific destination.
For the consumer market, these systems are usually very price-centric rather than destination-centric, although destination choice is a large part of any of these systems.
Within the corporate market, though, these systems are far more destination-centric, than price-centric.
For example: You're a consultant working for MegaGlobalMega Consulting Corp., and you need to travel from London to Miami, Florida on business. A good "destination management system" will allow you to input, control and manage a complete inventory and itinerary for your journey. You'll book your flight (usually online and in real-time) to Miami. Once there, you'll need a hire car. The DMS will know where you are, and should seamlessly allow you a choice of car hire options (again, ideally in a real-time, connected scenario) to car hire companies that are local to the place where you'll be (i.e. Miami, Florida). Of course, prior to your business meeting the very next day, you want your suit dry-cleaned, so again, your fantastic DMS system will allow you to book some laundry into a local dry-cleaners). And so it goes on....
Of course, if your business meeting was in Paris (France), you'd be shown dry-cleaning options in Paris. Of course, this isn't just car hire and dry-cleaning, but will usually encompass everything either the business man (in the corporate environment) or the tourist (in the consumer environment) requires during a visit.
For the corporate market, these "management systems" are usually administered by the individual client companies (and thus the employees of those companies) that use them and will very often allow very fine-grained control and administration of corporate travel policy, which can include things like:
Maximum spend limits based upon employee "rank" and destination location.
(This will vary by destination, since a hotel in Paris, France is much more expensive than the equivalent hotel in Grimsby, UK)
Alternate/forbidden locations.
Forcing usage of specific brands/chains in specific areas (due to the client company having a relationship with a preferred supplier).
In a nutshell, a Destination Management System, from a technical perspective, can be thought of as a central "hub" that reaches out to numerous suppliers and services all over the world (very often in an online, real-time manner using e.g. web services), allowing the end-user to purchase the products and utilize the services of the suppliers, which can be further refined by a corporate policy (eg preferred suppliers) within a specific "window" based upon geographic location.
Hope this helps!