So what were your thoughts of the town hall? Seemed dull and not very informative, looks like a new framework that makes us all accountable and will allow many to keep doing the same crap as today. And the Execs all said how excited they were at the Global Leadership Summit but on stage they were boring and unenthusiastic. Hats off to the Lady who asked about OTR! The OTR will remain broken when many positions are filled based on who you know and not best candidates. At least no one asked SM about flight benefits to Mecca this time for Hajj and Umrah!!
40 replies (most recent on top)
@R9lOfIr-8pjd all the whiners and naysayers, just go and educate yourselves on microservices. It takes less time to do so than to fight to death to preserve your "status-quo" and demonstrate how much you have to make up since you stop learning
Don't we already have "microservices" already? They communicate with each other using teletype, HSSP and MQ instead of whatever the new things will use.
Let's fast forward 3 to 5 years again. We are now half way to our new platform completion. The microservices use protocol buffers to communicate with each other. Nobody uses that anymore then and we ran into some bugs in that tech that nobody cares to fix. The code is too much for us to take ownership of. It has been thrown on the garbage pile of short lived new tech years before. We delay completion for 1 year to switch everything to the new sparkle unicorn protocol that a footbook intern just created in their spare time a year ago and which all the hot new startups in the bay are now using. A year after we finish that change, still a few years from our completion, nobody uses sparkle unicorn either. We discovered some bugs in it too. Nobody will fix those bugs. We don't want to own it because we don't use most of the sparkle that was needed by footbook. So we take a 1.5 year delay to convert even more microservices by this time from sparkle unicorn to fat monkey. Fat monkey is this amazing new protocol from planet wooba that was discovered when their super high tech scientist yogis figured out how to reverse time by eating antimatter burritos with carrots stuffed into their nostrils. Fat monkey is an incredible 0.2% faster than plain HTTP1 in 84% of cases. Using it is an absolute no brainer.
And so on...
@R9lOfIr-8anr Microservices don't share data. Also, they are versioned. There are plenty of challenges, but I'd say somewhere else :)
To the point of micro services, let's look ahead 3-5 years.
Group A B and C consume microservice "SabreData." Group A wants to add a data field "SomeNumber." Group B has a field for this built into the service that is consumed in their app, but it was called "SomeThing" and group A does not recognize this. Group C developed the service originally and it is version controlled, branched and has a version next in development. Group A is in a hurry, adds a field to the DB, alters the "SabreData" service then consumes the service within 23 unique apps.
Group C is pissed because this negates the work in version next of the SabreData service and group A introduced a contract breaking change sans change control to production that has a ripple effect in this architecture.
Alas, group A VP has a bigger ego and makes a case with his GE SVP buddy. So now there are 3 working versions of the same service in production that has broken some apps, but not others. Developers play a shell game of find the service with the correct source of record.
Imagine this scenario amplified to a power of X where services are numerous, located in a hybrid of on premise and in the cloud and you get the picture. New approaches? Devops? Services? Cloud? Just another flavor of the month club that will have a very intricate all eggs in one service basket breaking change effect if not done correctly.
@R9lOfIr-7cxp - you seem to lack tech competence needed in 2018. Yes, technologies don't last long and come and go. That is the new times, like it or s--- it. We have to first get modular so that we can rewrite pieces when needed. It's inevitable and no, there will not be one language and "platform" for next 20 years. However the key is modularity (microservices). Now, we are talking about rewriting whole systems and that is no longer feasible due to monolithic design. We have to get to a point where we talk about rewriting only components that are isolated/plugable so that we can tackle them separately driven by priority, need etc.
I'm invigorated by reading this post's replies in order. It's exactly what is wrong with Sabre and why it is in the predicament. today. Everyone has an answer, but not really. It's always tech idea vs tech idea - who wins. Someone drops in market competitiveness and the foreign concept of customer needs and speed to market. This, after someone rings in that the technology should last a long time, then someone else demands it should be flexible for 15 years.
This is what EVERY. SINGLE. MEETING is like a Sabre.
Marketing verses Product Development versus Technology versus Finance versus Customer versus Customer Customization versus AS versus TN versus Competitive Move versus Industry Leader versus Sabre Leader ego challenge.
Is this exclusive to Sabre? Doubtful.
The problem is not ONE person in our C-suite can harness an accountable unified strategy that does not result in executive infighting to be right, cloak and dagger passive aggressive fiefdoms that fragment just about everything we are doing, the inability to shift course before we spend a zillion on a product that customers do not want, need, or will pay for. Today, we have a former Airline CEO. His wheelhouse and experience can't even save AS. Now we have Bain Consultancy expert (bring in your own people and cut our people to solve the problem).
Where has the passion of our industry gone at Sabre?
Sabre's people and business culture is just like TPF. Fragmented. From Product Development, Human Resources, Marketing, and IT, but they do spend the big money on putting on extravagant trade shows & events and awful employee communications -(all PR spin and unicorns)
We can't change what we don't acknowledge: Sabre is a finance company.
The C-Suites experience - based on bios - reflects very little industry passion/experience - but one that's focused on carving up and crafting their financial exit strategy. It's what ALL airline execs do: They hire Harvard MBA's, former BAIN execs, former start-up golden children, and their network of insiders with "long tentacles" to sniff out the problem. Not for their love and experience in our business.
So layoff's should not be fretted, but expected. If you have any sense of business acumen you know this and should plan accordingly. If your boss is shutting you out, don't be surprised, be prepared. It's not all good, but Sabre has dumped so many executives and nothing has changed.
So it goes...
TPF on a mainframe is just code. Java on an Intel Xeon server is just code. The TPF code is simpler code than the Java code and the mainframe is just more reliable and more stable than the Intel Xeon server. That is why.
If you want to replace the mainframe then you had better figure out how because you will need something a lot more reliable and a lot more stable than the current Java code or the replacement will be worse than TPF and be more expensive too.
Whoever brought up Erlang is on the right track. That could do it maybe.
See how long you keep that airline customer business when they experience a sabre outage that delays all their planes from taking off.
See how long you keep that online travel agency business when that sabre outage causes them to be unable to make bookings.
See how long you can keep any customer if sabre is not reliable.
Reliability is number 1. Not time to market. Nobody will care if your product got to market a few days before the Amadeus one if the Amadeus one is rock solid reliable and your one has frequent outages that cost customers business.
geez.. there's this thing called "time to market" and, apart from few critical places, it's more important than "5 9s". TPF is not a magical black box that translates requirements to code but it is programmed by people and maintained by people. Usually few old guys, somewhere in the basement because TPF is ancient technology with almost zero demand which translates to poor salaries and/or lack of alternatives.
No Meltdown and Spectre don't affect TPF coz it does not run on Intel Xeon CPUs. It is a mainframe so it can be upgraded without down time so no patching complaints. That is why they have five nines.
If you want five nines on an Intel server you had better use Erlang and make it totally stateless. Erlang claims nine nines. You certainly won't get there with Java especially not considering how our Java is even stateful.
No kidding. We cannot rewrite everything annually. We need to get at least a few years out of it after its rebuilt. Maybe a rewrite once per decade is possible but that is very expensive so probably not. I don't think any rewrite can hope to match TPFs 60 year life.
When there is a sev 0 or 1 everything gets shut down because nobody understands how the 101 ingredients of nutty fruitcake strata of Open Systems fits together or what causes any problem. Understandably clueless people decide that any action must be better than no action so they start frantically randomly rebooting anything and everything until the problem goes away.
Will the new tech replacement fix this?
Just wondering, how does this Meltdown and Spectre thing impact TPF? Linux and Java patching is a constant royal PITA that everyone complains about but I don't ever hear any complaints about TPF patching. Why not?
Nothing in tech can last 10 years? How long can it last? 3 years? Have fun rebuilding everything every 3 years then. Where is the money for for all that development?
It takes us more than 5 years even to convince customers to upgrade to newer versions of the same product. They are not interested in the training costs of a new product.
How long is this new lego TPF replacement going to take to build? 10 years. Oh no, that new technology will be obsolete 3 times over before we even finish and 5 times over before everyone migrates onto it after 15 years. Will we start rebuilding it all again in 2021, 2028 or in 2032?
Maybe we should choose a different programming language each time and rebuild it all every year. Whatever sounds most fun at the time.
Should we build the GUI in VB? Delphi? SWT? Adobe Flex? HTML Guggenheim? Spark? Should we build the back end in Perl? ZOPE? MS ASP? J2EE JSP? PHP? Python Django? Ruby on Rails? Node? Clojure? Scala? Groovy? Should we store data in MS SQL server? MySQL? Maria? Oracle? Postgres? Mongo? Couch? So many tech fads come, and go. So many languages, libraries and frameworks to pad your resume with.
How did that turn out?
Great for those who leveraged their freshly padded resumes to jump to their next short timer gig.
Not so good for Sabre or Sabre customers.
Fragmentation fun for all. Maintenance nightmare. Stability in the sewer.
What technology will the new Sabre rebuild use? How old is this technology? How long will this technology remain viable?
If you rebuild Sabre then that technology choice had better last at least 15 years. If not then it will never be rebuilt again because Sabre will be finis.
Whomever thinks anything in Tech lasts 10 years is a clown. Get a beer, sit in your recliner, kick back, and think about all that has been developed in the tech world in the last 10 years that's even still remotely used. Gotta go....my flip phone is blasting the Cingular Wireless standard ring. Or it's my pager...
To Post ID: @R9lOfIr-6fck, When TPF freaks out, all systems have to sh-- down to fix the problem. Also, this is not conducive to creating new innovative solutions for customers. They are very clear that everything we create has to be customized for their more current systems. No customers, pissed customers, higher costs result in leaving Sabre and so it goes....layoffs.
I'm going to assume by your response you are one of the folks that have managed to TPF your way into near retirement and a high salary. Boondoggle without any innovation. Think of building easy to design, sell, implement, sell, and maintain in a competitive and profitable way. Did I mention cross-selling solutions and technology through the Sabre platform? Not going to happen until TPF at Sabre is eliminated.
When something is broken in TPF, which is exceptionally rare, the bug is found very quickly and fixed very quickly.
When something is broken in the piles of open systems junk that is supposed to replace TPF, which is exceptionally frequently, the bug takes ages to find and takes ages to fix.
TPF is rock solid, 4 or 5 9s uptime. The mainframe maintains linear performance degredation to 90% utilization.
The Open Systems uptime is just 1 9, and often 0 9s. It is terrible. The x86 Linux C or Java code has exponential performance degredation from just 10% utilization. The huge number of Open Systems each use different technology. Finding the source of any bug in this mess is a nightmare. Even finding the correct team to join a sev bridge is a nightmare.
Open Systems are only feasible as an alternative to TPF if it's also 4 or 5 9s uptime like TPF is. Reduce reliability and customers will leave. Open Systems are stateful and tightly coupled so an outage of any node causes a sev 1 impact to customers. Open Systems can only equal TPF stability by using a totally new 100% stateless share nothing design. Open Systems must be standardized to less technologies. No more custom C, C++, Java, J2SE, J2EE, Tomcat, JBoss, WebLogic, Apache, S2C, S2, ABCDEFG. Pick one technology per function and stick to it. If the technology will not last 10 years then do not chose it. We can not rebuild Sabre over and over and over. Build it to last the next 15 years.
Are you serious?
Since 2000, Sabre has been "working aggressively" to dump the "TPF spaghetti" for "Open Sourcing." Who uses TPF anymore? It has cost too much to maintain since....oh, 1995. The old guard of TPF experts costs to much, but are/were dumb as a fox....they configure job security in the TPF matrix of hell. Same with the Sabre Tech Execs. Sabre is consistent in one are. Executive (C-Suite) flavour of the moment projects that NEVER have a long-term strategic mandate. If so, TPF would have been gone long ago. Ever since Joan and Barry left, the Tech Execs will be citing Cobalt as the new saviour. This is such a joke. It makes me want to write a letter to the board...from this investor.
We did not have all these stability problems 20 years ago. Back then we had one simple coherent server platform. The client platform was starting to fragment though. Sure the TPS was lower but it was rock solid stable. The architecture was perfect for TPF. Not for Java on x86 Linux.
Cake???? Are some of your really concerned that you didn't receive your promised Birthday Cake? How old are you? I am more concerned that this company will remain here long enough so I can make it to retirement, long enough so I support my Family. Remember that Marie Anntoniet also suggested that the poor in France eat cake and that who situation did not end peacefully. These Leaders promise b---s--- goals to distracts us from the real problems. I hope that most of you can see that. $100 to all of us if we have no outtages which is impossible with the infrastructure we have create and now we have laid-off most of the talent that could maintain the system. Now you are upset about cake???
Sunset TPF is multi Year project with investment commitments . CFO promised the world and left .
Sabre will have to stay committed to sunset tpf , if they don’t. , tpf cost eats away - resources and contract to maintain and pay ibm license.
If your boss is in KRK and you are in DFW then it's pretty obvious what the plan is under the CTO. Offshore everything to Poland or India or both. If VS can sunset TPF and the current products then the DFW people will not be needed.
My birthday was last week
Didn’t get any cake or no cake yet for anyone since last Q of 2017 since the cake party was announced
Any idea of the leaders in Shared Services ( SSPD ) who work for CTO ? Big team there largely untouched from recent changes
Funny characterization , but sadly could be true
VS likes birthday parties, can barely speak english and wants to rebuild the entirety of Sabre from the ground up in 2 years using micro service Legos made of mystery sauce invented yesterday and expiring tomorrow despite not knowing how sabre works
WJ thinks all his apps are a micro service already so his work is already done
JD is like a possum frozen in the headlights of a truck speeding towards him
DS flubbed his lines and doesn't know the difference between Legos and Logos but he loves them if that's what his script tells him to say
RG leverages her extensive dairy packaging experience as it perfectly applies to a global travel software company HR dept and wants to shrink HDQ and offshore everyone in leadership, management AND workers to spread them thinly all over the world coz she loves flying on airplanes since she was 5
RS committed to fund Sabre Next and retired a week later so he doesn't have to worry about it anymore
CA is a Bain good ole boy with way waaayy too many Hilton rewards accounts
Fun times
Vish Saoji is a phony, so are DiFonzo and Shirk... Menke is bringing the worst execs so that he looks better, even with only 20% approval rate he is hanging tight to his chair. One thing common for all of these people: they are outsource-rs. Saoji, stop talking about AI-what do you know about AI? Everybody knows your (lack of) education and (in) experience.
I know VS said he likes to celebrate birthdays. I haven't seen any cake yet. When is that part of Sabre Next happening? Will the cake be for each individual birthday, every day, weekly, or monthly?
I can understand about 80% of the words that VS says but those 80% are mostly just BS bingo catch phrases in broken english. As for the other 20% I have no idea what he is saying.
@R9lOfIr-3cke I can understand VS’s accent and get the feeling like he is another useless C who enjoys the Party and Fun and not real work. Reminds me of ASPD’s own SR who left on Dec 15th. SR was a phony who loves his alcohol so I guess since he left we replaced him with VS. Sabre Next.....Next CEO, Next Layoff, Next what???? Our Marketing and Spin Doctors are horrible.
Does anybody else have trouble understanding VS's accent and grammar?
I am perfectly fine with all the Indian immigrant people I work with and have worked with in the past but VS is more difficult to understand verbally than anyone else I have ever worked with before.
Are his emails any better?
Isn't communication skill a requirement for C level execs?
OTR = Organization and Talent Review
@R9lOfIr-3dpj. You may be right looks like their plan to replace entire leadership with Asians ultimately.
And outsource everything...
Several of these new guys came from GE. Asian cheating network is still in full swing with Vish I see. He and Difonzo are masters of outsource look at old articles on them.
Vish Soaji is so phony.
Ai and Machine Learning! this guy used to run call center for GE, i guess in India. Not even a Software Shop.
In his four lines he had "If needed outside help" wink wink Outsourcing.
HR needs to be beware of this guy in wake of the hiring scams, kickbacks from past.
I've been a skeptic for a long time, but I see signs of hope here. It looks like we finally have some direction that makes sense.
Old Wine in a new Bottle - Same crap except that this is the New Year 2018
The Sabre ship has leaks which have not been fixed for the past few years. More importantly there are no good plans in place to fix these issues either. Ex - Operational Issues.
The ship is slowly but surely sinking. Enjoy while it lasts !!
What does OTR stand for?
It's crap like this that makes me doubt any OTR process. In an org of 10,000 no one is qualified? This was created for another outside ex GE buddy or Harvard School of Business know-nothing.
https://www.indeed.com/m/viewjob?jk=c9d70b17ae4acc9c&from=serp
Yes Sean hates cost cutting and he even said he has been doing it his entire career!!!!!! Did you catch that part? Yes OTR Not built by us yet our new tool will be the same format!!!! Wonder how much will be spent on the new tool?
Two takeaways I had were
OTR- "That was not us." Nevermind that we have Rachael reinventing the wheel and it sounds exactly the freaking same. It seemed to be a tool to see who can fill in asap when layoffs/attrition happen. There was no indication of AI to scan your skills and match them up to openings or promotion postings.
Next- rebadged more of the same with a shiny slide. Look! Customer Service! Look! Accountability! Look! We really do the technology! Saavy board members might notice it is a cut and paste job.
Most alarming was the mention of tough decisions in the budget and Sean hates cost cutting. Cost cutting=layoffs as we all know.