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!
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.
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.
Looking for NOSQL engines I found about GT.M here:
http://www.slideshare.net/robtweed/gtm-a-tried-and-tested-schemaless-database
At first look good, with SQL ODBC support. But I wonder if exist real experience with this? Somebody have use it?
GT.M is a very flexible engine that allows for NoSQL operations, but also is fast in cacheing disk to memory, as well as extensive enterprise level support.
I suggest you read the discussion by Rob Tweed at http://www.mgateway.com/docs/universalNoSQL.pdf
which would probably help you understand capability without jargon.
Don't have experience with it myself, but there is a list of some users of this database here: http://fisglobal.com/Products/TechnologyPlatforms/GTM/index.htm
From GT.M's Wikipedia page :
GT.M is used as the backend of their FIS Profile banking application, and it powers ING DIRECT banks in the United States, Canada, Spain, France, Italy and the UK. It is also used as an open source backend for the Electronic Health Record system WorldVistA and other open source EHRs such as Medsphere's OpenVista.
and
GT.M is predominantly used in healthcare and financial services industry. The first production use of GT.M was in 1986 at the Elvis Presley Memorial Trauma Center in Memphis, Tennessee.
From History of GT.M :
GT.M is licensed for use at over 1,000 institutions worldwide, ranging from small, community healthcare facilities and large teaching hospitals to some of the largest financial institutions in the world.
Also, from a recent presentation made by K.S. Bhaskar :
System of record for the two largest real time core banking systems in the world as we know of:
Production database sizes of a few TB
Serving around 10,000 concurrent online users + ATMs, voice response unit, web and mobile access
1000s of online banking transactions/seconds with full ACID properties.
Increasingly used in health care for for electronic health records
Operating database for at least one multi-sourced "big-data" project.
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.