My Greenfield return to office project will be to somehow stop TSG Senior “Leaders” from smoking for half of every day on the Mellon Green. Not only is this probably the most expensive waste of time and money in the bank, it defiles and ruins a beautiful outdoors green space. The guards stationed to watch the space smoke with them right by the many no smoking placards.
47 replies (most recent on top)
give us the real doo doo on greenfield, we need to know!
Sorry, @onho, but GF has nothing to do with virtualization and containerization. We've been doing that for YEARS. Every hear of bxp??? Well, if your apps were still on bare metal you wouldn't be able to continue that in GF unless you had a good reason. I already listed a dozen things that ARE GF in @elzd. I would have been pretty nervous being the CIO the way things were. It's probably criminal the way controls were neglected and ignored for YEARS.
And that's not to say there aren't issues with the GF rollout. One of the biggest issues the migration required tens of thousands of new userids and permissions yet they used the regular process to request them which could only handle a few dozen per day. Not to mention they made the app teams request all of them. Why would they give the app team a server that they don't have access to?
Nobody is saying virtualization and containerization are bad or on site servers are good. BNY finally caught up to where most other companies were 10 years ago. Congratulations. I think that's been said several times already in this thread.
Not only are you too d-mb to know what a greenfield project is and so hubristic you're actually proud of it, you can't understand what people in this thread are even talking about.
You, my mongoloid friend, are a worm wiggling at the bottom of the barrel of the tech industry. You and BNY deserve one another. Stay exactly where you are, not that anyone else would want to hire you anyway.
@mkeg, I'm sure it doesn't take much to boggle your mind if you can't comprehend the risk brownfield was to our company. Not to mention how standardizing apps will help drive us to a true devops environment.
What boggles my mind is the number of people who come here and actively defend BNY. This greenfield thing was an abject failure. BNY's corporate culture is undeniably toxic. The pay is below standard.
Is it some kind of Stockholm syndrome?
@kcai+1esW62RA you are a good stooge of the system :)
Take a chill pill. No one is forcing you to read this post. If you just want to know about layoffs, there are plenty of posts about layoffs. These are easy to find. Lots of people also use this site for company gossip and complaints.
it's a site about layoffs and you care if greenfield is completed... who cares if greenfield, redfield, yellowfield or orangefield is completed or not...
Greenfield and team cohesion is a joke. Their mismanagement and the new version of their new group moniker Transformation Services is a means the leave the bad taste of GF behind them. GF mismanagement and overspending for a solution that was obsolete and too inflexible from the onset in 2018 has had profound impact to all other teams fighting for funding since. The people at BNYM suffer daily due to the impacts GF has imposed on the whole ecosystem because their efforts are grossly inefficient and leadership of the team is not accountable for their failures instead they are being promoted at the highest levels. Sadly the good people work every day in the trenches will never get their due or their much needed relief. Stay away from BNYM I have never seen so many unhappy people work so hard to keep their livelihood alive, but CIO and CTO really don't appreciate the sacrifice.
@gpde, Name the apps that aren't in GF. From what I see, 99% are in GF, at least in Treasury Services.
Say what you will but Teddy Cho was a genius who knew how to roll out a marketing plan for what was at the essentially a long overdue mass server update. TSG should send him to present their budget needs in the future.
who cares.....
And the answers, children, are:
- @vxj+1esW62RA Project Greenfield is not really even close to completion.
2’) All targeted migrations are at least another year or two from completion
- Lack of hardware budgeting from typically poor resource planning implies a 2023 - 2024 completion at earliest; 2025 if estimates by the doers are once again dismissed.
- @fge+1esW62RA Greenfield IS not only a project, it has been THE major BK tech project for 4 years running
- @2qqh+1esW62RA BNYM projects are routinely 2 years behind due date
- @ziu+1esW62RA Evergreen concept is already out of date as the pace of the difficult rollout has been so much faster than the pace of the simple patching.
- @2qqh+1esW62RA
@forj, you have no idea what you're talking about. I'm and expert on "data servers" and GF was an absolute necessity and is a HUGE advancement for our company.
@fwai, you better let wikipedia know that they have the wrong definition of GF. This is exactly what BK is doing.
"From an Information Technology Service Management (ITSM) perspective, an IT organization that is being set up from scratch is said to start from a "greenfield" situation. This is because it would have no live services or practices in place to start with."
And don't lecture me about what I've worked on when think they we had to have 100% of the power available before we even started the project. Are you sure you're not a boomer programmer from the cobol days?
Teddy did not design GF
All this mess came from BNY and their leaders. Mellon already had a separate site with separate data servers doing all of this. BNY figureheads jumped on that and had a bright idea to buy new servers, put them in the same location as the main servers and then migrate everything. That's not Greenfield. That's a waste of money so BNY felt like they were advancing instead of actually addressing and fixing their outdated processes. It's created additional unnecessary pain points for everyone.
Yes and BNY is so 1990s.
@ffft+1esW62RA It's not my definition of greenfield, it's the industry definition of greenfield. The concept of greenfield projects has been around for many decades.
The thing you can't seem to wrap your head around is Teddy Cho / BNY made up their own definition of what greenfield means and slapped it onto a routine and mundane infrastructure upgrade project, tried to sell it as some kind of cutting edge technological advantage that BNY invented, and still managed to botch it beyond recognition.
The reason you are having trouble understanding all this is YOU HAVE NEVER WORKED ON AN ACTUAL GREENFIELD PROJECT. You don't know what a greenfield project is, either.
I've worked in Silicon Valley, I've worked at several startups, I've worked at tech solutions providers... for over 20 years! BNY's tech org is by far the worst I've worked with. And it's not just because of top-heavy management staffed by apes in suits from a bygone era. It's not just because they handle tech products the same way you'd run a Victorian textile factory. It's not just the offshoring, layoffs and cannibalistic culture of fear within the org.
It's the hubris that sets BNY apart.
If you really have the chops, go find another job in the tech industry. Get higher pay for fewer hours working at a place that at least has some chance of advancing your resume. BNY ain't it.
@eram, as I said, for BK GF a totally new datacenter with no reliance on the old systems. Sounds comparable to your definition of "no constraints based on prior technology".
And I think we only had a few bare metal machines in BF because they were too hard to migrate and going to be phased out anyway.
And VMs were so 2000's. All our Linux boxes were containers and our windows boxes would have been if TSG would have provided a solution.
@elzd+1esW62RA I thought I made it clear that I worked on "greenfield" when I was there. I'm very aware of what it is. What I was explaining is "greenfield" in the tech industry doesn't mean what BNY thinks it means.
I never said moving to virtualization is wrong. In fact, it's such a great idea that most companies did it 10 years ago.
The thing that is so hilarious about it -- besides naming the migration "greenfield" b/c it's an industry buzzword, while not knowing what that buzzword actually means -- is the VP who championed the thing... what was his name, Teddy Cho I think?... made it sound like it was some kind of new idea that he invented, when in fact BNY was about a decade behind the times when the project first started.
And the migration logistics were bungled at every step of the way. As you mentioned, a huge delay because the datacenter didn't have enough wattage for all the new equipment. The project has been going on for at least 4 years! That sort of architectural planning should have been accounted for at the beginning! You say it like it was some kind of unforeseen act of God that nobody could have known about, but it's fairly simple. We're going to need X new devices, each device draws Y watts of power, we have Z watts available... should have been architected long before the first rack was bolted to the floor.
Greenfield, everybody. Greenfield.
@dofo+, you misunderstand what gf is at bk. It is a totally new datacenter with no reliance on the old systems except it's under the same roof. So yeah, it's a a new datacenter with no constraints based on the prior datacenter.
Applications it aren't just moved to containers or vm's they are modified to adhere to rigid standards.
All software dependencies must be up to date software.
All software dependencies must be bk approved.
All software dependencies must be installed from the bk repositories.
All settings should come from our secret management system.
All apps must pass EH test.
All URLs must be F5 and have standard failover and health checks.
All gf servers can only be accessed via HiPAM.
All access is recorded on prod servers.
All apps must onboard logging to Splunk.
All apps must be monitored with appdynamics.
All apps must have dev, test, qa and prod environments.
etc, etc.
The project is HUGE and absolutely the correct thing for us to do. It certainly wasn't managed perfectly but it's amazing what was accomplished. And it was delayed because of power limitations in the datacenter. Now we're on to failover and stay and standardizing auto build/deployments which is also HUGE and the correct thing to do.
Wow, when I worked there 3 years ago this "greenfield" thing was the top priority and was scheduled to be completed by early 2020 or something.
First of all I was confused. After working at startups and tech companies, I come onboard to this bank and they're calling the move to virtualization and containerization "greenfield", which is absolutely not what the term greenfield means in the tech industry.
For anyone who's confused, a "greenfield" technical project means you have a specific goal and you achieve that goal using any technology you wish in order to accomplish the goal as quickly as possible. A new project with no constraints based on prior technology.
An example would be, I want to create a new website for my company. The company's current website is running as a monolithic application using Java and Oracle, but I'm going to stand up the new web site using microservices built in Golang and MongoDB because I can get it done with a small talented team in a few months. Converting your entire corporations IT infrastructure to virtualization is not greenfield, it's an infrastructure migration. No new applications are being built, you're just shifting the old junk onto a new back end architecture.
So anywho, it's no surprise that 3 YEARS LATER that mess is still not done and from the sound of it, nobody cares about it any more.
To anyone who is still working there in the tech org, please, PLEASE do yourselves a favor and move on to another company. In my case, I was laid off and in less than a month I had another full time, 100% remote position earning more money at a company where I am appreciated, have been promoted twice, have better benefits etc. BNY's tech org is a joke and you won't fully appreciate it unless you've worked somewhere better, which is just about anywhere.
Oh no. The way that they treat technology workers is absolutely unconscionable. These people LIVE their jobs in a way that Senior Leaders never would or even could.
who cares
Our Y7 appliances were migrated to HD4 last year. Hopefully we'll also move W5 to JKD7 also in 2022. The standard we're looking at is that JIR27 gets centralized into GFX27. I think that container-based solution should get us over the finish line this year. It's been a long road but hopefully the end is in sight.
@9txa, yeah, then they "eliminated" my position last January.
Wow, your team is really nailing it. Congratulations on a heck of a lot of accomplishments in a relatively short few years.
@6fjd,
All of our windows servers were migrated to gf VMs 2 years ago. Hundreds of them by the time you look at dev, test, qa and prod. They still didn't offer any windows container solution even though they said it would be available in 2019.
All of our MQs outside of the mainframe were moved to MQ appliances in GF shortly after that. I think dev and test are actually VMs but they are definitely in GF as we migrated the URLs and permissions when we migrated.
All of our DNSs were standardized and migrated to GF F5 as part of our migration.
I believe this is the case for 99.9% of systems in Treasury Services.
@2rxr+1esW62RA most all MQ installations are on BF servers? Brownfield legacy storage? Legacy Oracle? Legacy DNS? Legacy Windows servers? and many more.
Pay no attention to the man behind the red curtain.
Who runs TSG these days anyway? Any good people still there?
Or even have a pilot.nexen.com url that would only allow pilot users to log in and automatically uses the pilot apis. Then nothing has to be changed in the api store. You could pay for it by the OT saved from one weekend of deployments.
@3igm+, How much does it cost? For instance, for nexen web apps, it seems like you could create pilot groups or add an attribute in ups and add the users to that. Then duplicate the api F5 URLS with and prefix them with "pilot." Then update the api store to to route pilot users to the pilot api. Then at any time, the ops team could move a server from the prod api pool to the pilot api pool, deploy the changes and have the pilot users validate them. Or something like that...
Half baked, half assed
@3ewz+1esW62RA - As a TSG employee I’d love to take your approach. When budgets are submitted for this approach we’re laughed at and told to do it quicker and cheaper.
@3csq, it's actually typical of the bny business areas to think they can just leave technology as it is. Things change whether you like it or not. Software needs security and updates. Applications have to be modified to use the supported versions of other software. Additional resiliency and failover is required. Users expect more and more and will gravitate toward companies that offer it to them. Not to mention all the basic deployment processes that are lacking in bny. Does your gmail go down on Saturday morning for software updates? Why do our systems? Why don't we roll out changes to servers and route pilot users to them until they are validated then roll out additional users and additional servers? You know why? Because TSG doesn't provide that solution to application teams.
"BAU phrase of continual application refresh" - yep, typical BNYM techno-babble
@2phv, it isn't true that all the GF applications rely on BF.
How come all of the Greenfield applications still depend upon brownfield?
Despite what the other posters are saying, it is in the 90+ range of completion and taking on a BAU phrase of continual application refresh.