How the RFP process has improved with composable architectures

foreign [Music] we are live and somehow that 30 second countdown music got a bit on my nerves I don't know why that's not let's not complain the first secondary in the live stream but it's just like that it's strange timing wise yeah just uh as a musician it was bothering you I don't know for me I it got me excited oh well that that's all we need like as a musician what do you want is be in the pocket that's what they call it so it's slightly slower than the click that means when it starts to groove and I think maybe in this one the high piano notes were just too far out of it but that's not for today's stream today we're going to talk about some different stuff and maybe Mark you want to kick off um by first saying who you are what you do and then also what we're talking about today uh let's see I am Mark domini from uniform and we are going to talk about uh a bunch of things uh really is specifically talking about uh rfps and evaluating content Management systems and uh this is part of a larger series and we encourage everybody to go and download the guide that we produced on on how to evaluate content Management Systems uh you can click on that QR code or you can go to this uh link on uniform.dev and I think this is going to be a really fun topic because I've you know we've both been in CMS for a very very long time and we've seen the way people evaluate and and procure software change dramatically and yet there really has not been a similar change in telling people how to evaluate software you know if you look on uh do Google searches on uh content management system rfps you'll see a lot of kind of questions that were designed for the best practices 10 years ago and and we'll actually look at one and kind of parse through it and say well a lot of these things don't apply in the same sense that they that they used to so you know we'll we'll compare those things um and really as well I think another big one and and Tim you know this more than I do um how how organizations work with content management software has has changed pretty dramatically as well a big shift from it there's kind of this pendulum between it and marketers and I think headless as well has shifted very strong to developers um and so you know a lot of that you have to make sure your organization is aligned around that as well and and then of course you know we're going to talk about how digital experience composition platforms like uniform can help with this process as well I think this is um pretty important because it's it's one of the big value propositions for what we provide so that's that's pretty much the what we're going to talk through today so am I safe to say that everybody will know after this stream the difference between how we used to affiliate software and how we do it now in a composable world and then perhaps how something like a dxcp can help you to work a little bit more efficiently and because of that now perhaps change again how you would affiliate software buys or buys or procurement that's that's the proper word right yeah yeah I I hope so that's the goal we'll see people can comment and let us know if we hit that Mark but yeah that's that's probably what we want to accomplish all right so how about we start with our first agenda item here which is kind of let's let's have a look at how these RFP questions and ways of choosing software for whatever problem you're solving how they used to look and maybe Mark you want to talk a bit about what your experience is there yeah so that's that's a good point we're gonna pull up uh an RFP template from a company called uh dot CMS and you know to their credit this one you can actually uh download you don't have to fill out a form uh which is which is why I thought it was worth um talking about uh a lot of vendors do this though if you do a search for CMS RFP um the majority of vendors have something that looks like this document and often it looks a lot like a spreadsheet and this is this is sort of the format you know basically um this is for you know you as a client evaluating content Management Systems you're going to send this to vendors and vendors are going to fill it out and send it back to you and then often there's a process where you're going to look at each of these criteria and you're going to uh score the vendor's answer and then you're going to go through each of these criteria and provide a waiting uh you know how important is certain functions to you as an organization and then at the end you're going to come up with this quantitative uh assessment and you're going to score the vendors and you know maybe do some more demos or a bake off or concept or maybe you'll just buy uh based upon that that scoring and you know I I went through a number of these I I bought software this way uh when I was implementing uh or you know looking at content Management Systems back in the day when I started inside um when I was at sitecore I filled out a lot of these over the years and you know the funny thing about this is even though you're sort of wrapping all of this in a very quantitative process scoring the answers waiting the answers coming up with the score typically um all of the answers that are being provided by a vendor are very qualitative and you know this this is especially true through for you know technology functionality you know a really good example of this is like uh you know does your CMS offer a command line or you know how does your CMS fit into a CI CD pipeline setup uh these are actually good questions and these are sort of you know semi-modern uh questions but you know something like how does your CMS fit into a CI CD pipeline setup um no matter what the vendor can write as an answer um it's going to sound somewhat the same even if the the actual um implementation of that differs you know really dramatically and yeah um you know I think about that vendors that do CI CD quite well like say uh contentful right you've got this concept of environments which are essentially branches for your content you've got this concept of web hooks being triggered from content model changes which are really important for you know Advanced CI CD operations um you know you can sort of swap environment names and and that allows you to do rollover you know really well you can do rollback like you know these are pretty um complex things and yet until you kind of see it for yourself it's it's really hard to know how much of what the vendor is saying is you know actually true because a lot of other vendors even if their capabilities aren't as good on paper the answer would look pretty similar right yeah exactly yeah so I've I've been talking for a while there I don't I you know Tim I assume you have also seen the same oh yes many of them and you know what's interesting to me is like and we talked about this yesterday a little bit in our meeting to prep this um in my career at agencies we of course had to fill out these rfps on our end not just for cmss but for a much wider range and what we saw a lot is that these rfps were created of course by the brand that thought they needed something describe their problem almost in these questions and then see hey can the agency now based on their Tech choices fill out these questions and we can quantitatively weigh in these agencies winning and that's so incredibly hard because as it turns out um you need an agency for a reason right or you need a specific CMS for a reason because you have a problem you cannot just solve right now you're paying others to do it and then when you make questions like these in your own context you might know your business really well in certain aspects but maybe on others it's a lot harder because it's highly technical or there's some very complicated puzzle pieces that need to come together for both messaging but also how things connect technically and so we would look at these questions more often than not and say yeah I think we can answer this but I'm not sure it's going to solve your problem because you're putting your internal processes into these questions and then don't offer a wide enough range to actually solve your problem in a way that this agency deems um the right way that's most sustainable of whatever and it that can sound pretty negative but it's not because you always have internal politics that to come into play in these kind of questions right and so funnily enough um the rfps that we would just fill out exactly what the questions were we tended to not win and when we did win is when we actually threw away this thing and kind of answer the questions but in a pitch with a story that caters to the problem with we thought they had and the more specific these questions get like is your CMS cloud-based or on-premise like those kind of things it's it's interesting to say yes or no to this but it sometimes on-premise will just beat cloud-based I'm not saying this is fully true in a composable thing but it might and if you have a story to tell it's a very different way of dealing with these so that's my history with them generally when you make a lovely story about something that actually solves somebody's problem um it's a lot easier but that also means you have to really understand all the tech and all the problems so maybe this very long answer just explained how complicated this is the conclusion here no you you raise a good point and and this is also true even in the the sort of uh older area of CMS systems we would often see uh rfps that were much more narrative driven and and that is definitely the way you should be approaching rfps today and certainly we recommend that in the guide is really to say you know how are your different user groups uh and personas accomplishing their job what do they do on a regular basis and you know how do they how do they accomplish that a really good scenario that I want to remember um and I still remember it to this day probably 15 years later because it was such a great scenario was um a Cosmetics company basically saying hey we uh we're a large Cosmetics company and we enter into contractual agreements with uh famous people to endorse our brand but the contractual agreement ends at X date therefore we need to have a system for uh finding every asset finding every landing page related to that asset that has this person's likeness on it and it needs to be removed by such and such a date and if it if it doesn't and you know the famous person sees their picture still on the website the day after they're going to come out you know come back to us for you know violating the contract and it will literally cost them millions of dollars and so they have this as a scenario and that made a heck of a lot of sense because that was super important to them and it involved um you know folks on sort of the legal team team and the licensing team working in this finding those assets identifying them how to pull them down you know obviously you want to get the benefit right up until that day but no further than that so it had to be a very uh and and so this scenario was great because it had all of these teams what they did what they needed to do what they valued uh how much they valued it um and you know that that's the exact type of scenario that can apply really well in a composable era because you can be you know looking at this and evaluating it and kind of building that thing out in a proof of concept live as opposed to relying on the vendor saying this is how you do it you can actually figure that out yourself and and learn along the way and I think you know correct me if I'm wrong it's worth putting in that effort because no matter what system that you pick you're going to reuse a lot of what you whiteboarded and a lot of the logic that you built in evaluating that and so you know I think the the upshot of all of this is uh instead of considering the RFP phase and the you know proof of concept phase or implementation phase to be very separate things it actually is is much more of a Continuum you know you should be looking at those scenarios building those things out and testing those and kind of incrementally um doing that and I think that's that's one of the big learnings right yeah and we tended to call these continuums Discovery faces and then in the older days customers wouldn't pay for a discovery phase because you as an agency are just supposed to know what you're going to build but the more we're going went more into like the agility of fast releases MVPs and then updating tiny little bits to make it better better better doing a proper Discovery phase is actually we could almost call it like our Sprint zero but then we just make it two months or something where you actually work on what is your core problem which puzzle piece did you did need to put need wow you have to put together to actually make this work and now suddenly a discovery phase is literally part of a bigger project that is paid for and a lot of the questions that you might not have answered from a traditional RFP will be answered in this because you're workshopping this you can even figure out how many developers do I actually need in these kind of situations it can be very agile start small and add it where you want and that might be a lovely Bridge into if you now have a composable system or Modern Way that's also a very agile approach to stuff you might not need a CMS right away first you need to solve your story and then what what are the things that you need to solve your stories probably it's designed its messaging or even if it's processed making sure people understand what they're dealing with content-wise or where content even comes from like the thing you just talked about like with your celebrities with these images that are on the screen but at a certain date they have to go just finding these images from all the different media Outlets that actually have shot them or created them or whatever that alone can be a project of two months and so I would almost say being super agile and doing things in parallel and having the tools to actually do it in parallel is where you start to win it is just again it's a it's it's a bit of a complicated thing to do but it's it's nicer to be able to do stuff in parallel and be able to change things really fast and keep things small all if that makes any sense yeah well and I think that that kind of goes into one of the other points that we wanted to talk about is that um a big part of it you know you mentioned being more agile doing more in Discovery I think that only happens in general with a larger organizational change right you know if if you're a newer organization maybe you're you're doing that already but if you were used to an old CMS more of a waterfall process that's a really big shift and I think that's kind of important to note is like if you're looking at composable systems you also need to have that organizational shift um to really support the model of of how these composable systems work because if you if you don't you're really not getting the the benefit of it um and you should be making that shift anyways and so it's it's interesting for me to note you know kind of initially being on the outside as I was an older vendor and then being on the inside of composable systems and seeing how organizations uh take that on those those two things really have to happen in parallel if you start looking at composable systems but you haven't shifted how the organization thinks and works and then you know thinks about digital projects you're you're going to have a hard time um and so I I think it's really important to call that out yeah and this is why I wanted to do a quick call out to where I used to work at at faltec where they actually started to call projects business Transformations so it's not just a tech team that changes it's an actual business change because like all the process we do have a lovely comment from Paul so let's put that on and see if there's enough space to read it out it doesn't look like it but yeah so my clients have moved on from rfps in the traditional sense we never use the typical checked list process this is the way we work one so write up our business objectives and strategy to brief three short listed vendors that makes a lot of sense yeah I do want to know how you get the short list though because is that opinion experience you know all that stuff that's an interesting one it's also cultural because if you're in France like me you know somebody from high school they're on the short list if you're from the Middle where I was born it's pure Merit right so it's quite different than to invite Defenders to a meeting where they can see anyone and ask any questions we often judge Fenders by the questions they ask and how to conduct these Discovery sessions that's awesome I love that and then we invite them back two percent strategy level on uh how they can support meeting yeah so actually the the comment is a little too long so we cannot read everything but I think Paul you're very close to how I think it's just more agile it's a much more human approach to story also it's really interesting now Paul's Paul's bang on and it's it's funny um you know he said yeah we've we've already moved on past this and I know when you know Tim you and I had this we were talking about this topic you said the same thing valtec has already moved past this and I think there's there's a little bit of uh shall we say uh like Survivor bias there because you guys definitely are on The Cutting Edge but I I know there are still organizations out there that are you know looking at this RFP format and still thinking this way um and so um yeah in some sense I think to Paul we're preaching to to the converted um yeah exactly you know he's and and Paul's a very sharp guy I you know I know him personally as well uh so I I know he knows what he's talking about and so in in a lot of ways this isn't necessarily targeted at Paul it's really targeted at you know the people that are still looking at some of these questions and you know I think we we discussed a little bit further about things like organizational change and how to run the evaluation process differently I think there's there's probably a few things as well that you can look at in a document like this and kind of call out and and see things like uh you know can you provide the system requirements for your solution for CMS end users this is quite funny because most CMS end users nowadays it's just the browser and and this question is is sort of like okay well back in the day it might have been they would need to install a client and you'd say oh it's it supports Windows and Mac uh you know similarly I'm not old enough to have needed the client to run a CMS I'm I'm I'm fully in the browser space I think yeah well I mean this this question could it could be read one of two ways you could say like oh well it's you know Chrome and Firefox and whatever or but you know this this has its roots way back when when you know CMS systems had client requirements and and nowadays you know so much of that is now just cloud-based in server um you know similarly you know what programming languages your CMS written in uh headless vendors may choose not to answer this whatsoever um oh yeah because it's kind of it's irrelevant yeah well it might not be which makes this interesting to me as a developer if a CMS still tells me we've written this CMS in erlang or some crazy language right me as a different will judge that somehow and it it might be bad it might be good but if there's now a new headless CMS written in PHP I as a developer with my history of PHP would probably say maybe not this CMS even though it's completely sorry for my French but yeah you can be great Facebook ran on that for a long long time right so it does you developers judge and so if you're headless in SAS in the end the only thing that I think matters is your security your uptime and your performance yeah and then build it in however you want just don't say it I think that's the best move yeah no that's that's an excellent point uh security uptime performance um and it's it's interesting like you would see you know some of that in this question you know do you throttle traffic or have API limits uh oh yeah you know but in general uh you kind of have to go I think pretty deep in this before seeing questions that kind of touch around that um but you're right like I think the this is a really key point the value proposition for what you're buying has changed very significantly in for composable vendors versus what you have for in the past um and and that's that's an excellent example security uptime performance um you know those are things uh you know where your cdns and data centers are located um those things often aren't showing up in some of those old school rfps and they're quite quite important for um how composable and SAS vendors deliver software yeah sure especially when you deal with users and gdpr and all that stuff yes exactly um so yeah all that to say um you know some of these older formats are uh not necessarily aligned well for for you know newer use cases and and we'll you know I'll put up the link again you should download this this hopefully goes through a lot of that new criteria yeah exactly and helps you in that case uh so let's see here I think let's let's talk a little bit more about um how developers should be evaluating and and really you know I think we talked about it a little bit where we said you know some of the older platforms marketing was driving that effort and now that has shifted back to developers and developers have much more of a role in you know either evaluating software or or especially still having kind of a veto on on what's chosen um why don't you talk a little bit about your experience um you know doing evaluations and doing self you know self-service and trying things yourself and you know what that means to you now versus how you work with software in the past yeah sure so back in the day and this is not even that long ago the first question we would ask does it have an API that's a crazy question right now but that's not even that long ago because what we always struggled with as developers is that if a CMS came with a whole Suite of Awesomeness um you're kind of stuck to that Suite because you don't well sometimes you do want a famous very simple and accelerated front end that you can just theme without touching it right sometimes that works if you have to build like 800 sites but then um you when you do that you're kind of stuck to what Defender decided at that point in time when they released it that that was the best thing to do combining all the things but a year later that's probably no longer the best thing to do and so we would always ask is there an API and how flexible is it and is it actually run time is it fast enough or do we need to do some other stuff here and if that was the case we can then build our own front end and have it separated and then you could choose all the things you wanted to do and of course nowadays it's slightly different because they all have an API and they're all probably really good they're just different flavors of how you query a rest API or there's a graphql API and as long as they are flexible and fast we're good to go and so some cmss lack um certain features over others but you can always overcome them I think nowadays that's no longer really an issue of which data can I get in which way and if it's really too bad we just ask a back-end developer to get the data and give us a little microservice in between and we can just get it from there so that is generally fine but what we have now noticed when you go slightly away from just front-end developers but more like the the whole stack of tech is that you want also apis for management what I think is sorely like you know a lot of cms's is being able to add content into it through an API sorry going I yeah no I was gonna say um I agree 100 on that and I'll actually go once one step further even so you know when we're thinking about um content management apis um you know some say like yes you can you can add items at a time can you do those things in bulk um yes bulk Transformations uh I think you know being really Frank bulk is one of the Achilles heels of headless systems um on an on-prem system you could pipe data back and forth you know you're sort of owning the the yeah closer to the metal so you but like we've always had these issues where we'd have to move data from the one system to the next because we're doing a green field project but the data needs to be somehow mapped and moved that never really worked even with the most fancy SAS headless cms's it was really challenging and even just recently yeah I won't name the CMS I was trying but I had to import all my conference talks and I have I don't know 200 or something and I couldn't do it in one batch it couldn't do it in parallel and it was just choking and giving me errors so I had to do is make a cue and wait for 1200 milliseconds between the thing imagine have if you have like a a proper data set not my 200 measly conference talk without Edge connections right it's just simple database that would be then a two-month project to make that work yeah and so yeah Management apis in bulk is is a huge thing yeah and and also throttling on the management apis and performance on the management apis relative to the content delivery apis you know I think every vendor will say yes we've got a CDN it's worldwide you know under 100 milliseconds for Content delivery um you know X number of requests per second which is a fairly High number and if you ask for the same on the content management side a lot of them will um that's the answer yeah sometimes you get that or if you do get it you know as we were talking earlier the the throttling on uh the content management API is is really not meant for uh bulk operations and so yeah um you know it's kind of funny I think back to uh again when I was on the client side and we sold software digitally and we used uh Digital River um you know back in the day and uh you know this was before the shopifier and various other things for Digital River you would you would upload a CSV and I remember thinking like this is the clunkiest especially you know POS um and and funny though I come back and I realize uh uh having seen like bulk upload capabilities for a lot of systems uh CSV is actually uh probably the most efficient way to do it because basically you have this upload task you can upload this giant whatever hundreds of megabytes of asset and then it's going to process in the background on the server um so you're not constantly having this back and forth you don't have to worry about failures and restarting and you know all of those things um for that task of managing things in bulk uploading a CSV was actually extremely efficient and this was going to say that but you did now but there's also other things like think about setting up a new environment for a new QA person for example I'd love to do that by code and do it fast without having it sandboxed or because what you notice is certain Systems sell themselves as okay we're Cloud native we're SAS then you ask for a new playground somehow and it takes them a week yeah are they clicking boxes in a devops environment to spin up a new box for you if that's the case there's it's fine if you choose to do that and that's in your contract good to go but as a developer I just want to be able to just do one click and have a new thing like condentful does or like uniform does that's so simple if it's built a certain way that just works and so yeah there's lots of those little convenience things as developers that we would love to have I think yeah I think so when I was saying you know I'll take that content management discussion and go one step further that's exactly what we're talking about like the ability not just to manage your content through apis can you manage the application itself through yes exactly and I think that that is much more important especially as you get into Enterprise scenarios because you know to your point you want to be scripting a lot of that if this is something that you're doing on a regular basis you're spinning up new environments you're adding new products you're building new landing pages websites whatever you don't want to have to click through Visual interfaces every single time you do that and that's a manual human task you want to be scripting and automating that yeah well just look at all the cloud providers they do that extremely well it's almost like they make the clicking through the interface terrible so you just start scripting Yeah well yeah it it just don't ask me to set up another free S3 bucket because I honestly forgot how I did it the last time right so exactly uh so let's see here there's there's a few other things that's it's kind of uh worth going through and and looking at um uh let's see here uh [Music] um upload uh personalization uh search capabilities I think it was up near the top prices so much here oh here we go provide details on your product versioning and release schedule I think this is and and the roadmap this is one of the ones that's that's um probably one of the biggest kind of cultural disconnects between old vendors and new vendors because a lot of SAS vendors will say the products live the product is the product you know we'll when stuff is built we add it into the product immediately and release it um you know you look at older vendors and the versioning and release schedule was very important because you as an organization would have to say hey we're going to install this and do we need to know if we're going to go have to go through an upgrade process on a you know six month basis a yearly basis you know what is what is that and then similarly as well product roadmap for the next few years you know a lot of older vendors Enterprise vendors this was a really important question to answer because you would want to know does the vendor understand my business and are they building features that will be supporting my business as my needs grow and change and I think this is one of the big ones that um you know SAS SAS and endless vendors um probably don't provide this you know beyond six months yeah that's about it probably maximum yeah if they provide it at all I think it's a very different philosophy and how how software is is delivered and so I you know I think this is pretty important to call out where you know you're going to have a bunch of vendors saying I will give you you know we'll let you know what we're releasing in three to six months because that's the stuff that is literally already in the development pipeline you know to be released it's already been agreed upon you know people are are developing it as opposed to you know older vendors who would say like oh we're gonna build this and then think about this and then think about this and you know only that first three months of effort has actually started um so that's that's a big difference I think this this certainly also reflects composable in general though which is you know you implement on what exists today and if you get new features from that vendor that are aligned with what you need great but if you don't and some other vendor is starting to provide those you want to be able to switch you know you can switch rapidly to that that other vendor and I think the the lack of focus on long-term roadmap is less important in exactly a composable world right well it's they have smaller feature sets anyway so that makes it easier also but like as an example I've worked with a legacy system quite a lot and at one point they said you know what we're going to do everything in Docker containers so start preparing yourself for the future so a lot of people started doing that including our team we went into it deep and it worked really well and then they decided you know what pass is actually better approach to this thing so you could still do the docker thing but we prefer the fasting and you know what maybe it will be SAS and this has happened in like a year and a half so imagine having a big system that you rely on that you have to use with all the upgrade paths and you invest as an agency to understand this one Whatever offer they're coming out with and then they decide to Just Jerk it around and in three months and do something else the bigger the feature set the harder that is to deal with and we've no we felt that right and when you work with a SAS company like a headless CMS or a search engine that alone is a smaller piece of of feature set and so let's say it's only payment or let's say it's only a wish list you can just swap the wish list to another one and the rest of your system still is still alive so that that's a much more interesting and easy approach I think yeah well and on the subject of switching systems I think is is now a good time to talk about digital experience composition platforms or is there anything else we want okay no I'm good with that yes perfect so I think you know full disclosure uh Tim and I work for uniform which is a digital experience composition platform and you know one of the it can do a lot of things but in the context of what we're talking about today and evaluations I think it's it really has some useful features to help organizations um work side by side with what they have in place in their existing organization and also how to evaluate and how to make it easier to swap those things out and and really everything that we've been talking about about testing vendor for yourself evaluating things for yourself testing those those user scenarios I think uniform can help with that yes and I think I might not want to specifically talk about uniform but more what this dxcp thing allows you to do especially and so I'll just keep it close to my heart as in let's talk about how agencies could work with this right when you're producing something for a customer and you're using tools because what you want to do is be as fast as possible to fail you because the moment you show fail you they'll give you money right you can convince them in a pitch and they'll give you a bit of money but if it takes a long time to show them value and your name is not Accenture or something they will at one point say where are the results people and if you then show Half Baked demo you're not good to go right so fast to failure is the way and how I see fast to failure is in process to be able to do things in parallel a lot more and also to what that gives you is that you can have you can delay certain choices and you can pull forward other choices which is very interesting and so for example what we always saw is that okay you have to choose a CMS and that would dictate our whole process so without the CMS choice um we wouldn't even start with um coding anything on the front end or I guess you didn't even know what kind of components or what capabilities the CMS had to do component based design and all of those things and then you can also not start QA it will delay a lot of things based on the the abilities of what that CMS could do for what you could do design wise and messaging wise and storytelling wise and so if you are able to start with a tool where you don't need a CMS right off the bat where you can do a lot of Explorations already in that tool that is the same as your production basically and I'm thinking about things like user Journeys how URLs will look your whole site map we used to do that in Discovery and we would just put it in a Wiki somewhere write it all down validate it with everybody and then at one point you have chosen all your systems and your software and you start to slowly build it out and then that whole site map of how where everything lives starts to do something well when you have a dxc or dxcp like uniform there's literally a size map editor in there for your whole headless architecture or a composable architecture which means you don't have to go to some Wiki or notion or whatever and write down all these things and then hopefully it'll connect no you literally do it in the system your dxcp that is already production ready and you you just put all your placeholders in there and you point everything to compositions that are Pages or you add some redirect rules so like that URL might redirect to something else that you already had that is from an older system so that is a small thing you can pull forward and directly do in your in literally software that will you will use for your production and that same thing is and we haven't really explained what the dxep is here right but I'll I'll let you do that in a sec Mark but what is very interesting here is that in a dxcp you can have all your design components right into the system and then when you put these components together you have a page a composition and each component you can then point all the fields of that component to different data sources that are external but if you don't have a data source that's external that you point to you can also just hard code it in there you can literally type in the fields this is my title or all that stuff and so without diving in how all that works I'll leave that to Mark in a sec that means that a front-end developer when they already have some design stuff and they have components that they like they can literally build these components let's say in a storybook environment so to literally just see these summer components using my properties and put these in a production code front end and then that front end sits into uniform and you can literally just code everything and type in the content by hand in in a dxa um that would potentially look like whatever your final page would be but there's no real data connected yet from the outside and so that means your front-end developers can work without even having to think about what a back-end developer would do or what an API would look like nothing you have designs you have properties for these components you just build and so that's when your QA can start immediately even even use any backend developers you haven't even used anything else right and so everything is now more parallel and at one point when you did choose a CMS and a data set and how everything works then you just map it into the DXE you swap out what the props connect to and you're good to go I hope that was not too fast and too crazy what do you think Mark no I think that's uh that's an excellent explanation and I think um you know what you talked about about having those tasks in parallel that's that's probably the biggest value there you know yeah because I think your point about time to value is is absolutely key especially in this day and age and if you're having to do those things in parallel you know a big part of the focus of organizations is how to uh shift to be able to do those things in parallel very very quickly and you know have agile teams with developers and marketers side by side and you know and I and I have seen that work for organizations right they have I've done it myself but with a lot of process and complexities and Becca developer would come in and say Hey you made this front-end component with certain expectations but I can just not map my data that way yeah well what if you had a dxc that set in between and that was not even a discussion that's nice exactly yeah basically both sides are doing the tasks that they need to do and and you know instead of having to come up with um you know essentially uh you know documentation on here's what I need my component to do or connect with or whatever and hand that to the developer and the developer does the work and you know builds that into their glue code or you know back in for front end or whatever you want to call it yeah both of those teams are basically just working in the tool and the the you know output of the tool is is essentially self-documenting right you know and it's and it's the the other thing that I think is interesting as well that we've seen is you can kind of start from different points of view um you know we're we've been talking about a kind of a green field use case where you're starting from scratch and we'd say okay you start to build these things and these structures and Scaffolding and and whatever in your dxc p and then your front-end developer builds the front-end components and then you might map it to some back-end content sources and customer data sources and it all just sort of comes together in the real world often it's it's the other way around where you have an existing CMS and you need to work with that data so you can say great we'll start with that and then start to do the mapping and then you could build a front end or maybe you're coming from the other way maybe you're coming from the front end and you have those components so you can do that first you can say right pull those components and those properties and and all of those definitions into uniform and then you can you know sort of work backwards in mapping that to underlying content sources so I think it's sort of the flexibility to say you know not just having a single way of of working you can actually start from different points and yeah sort of make those connections to the the other teams and processes yeah and having something like a dxsb um product as in uniform normalizes this thing for a lot of people because I've worked on world famous brands that has like huge 60 markets all that stuff and they had this old website that was completely monolithical everything in one and it was really hard they have five teams doing QA all day on that front end and that back end and it was just not working so they realized at the point that their release cycle was 48 hours for One release if he did a CSS update right a styling change so they realized okay we need to separate this front end from this back end and then move this forward and be time to fail you really fast so we can release every day rather than every you know few weeks and then the whole team would burn right and so um I see we have a comment but I'll finish my story and then we'll put it on um so I think we don't we don't need to hear that comment oh I read it though it's worth mentioning the company is called uniform and often we get a lot of clothing manufacturers trying to uh sell us on uh supply for Fabrics we got some spam this is the best spam ever you know what just for good measure is just too much fun look at this manufacturer and supplier of high school and college corporate security neckties let's anyways okay yes it's probably worth worth talking about why the company is named uniform is really to help I have built a uniform customer experience across all of these different systems and processes exactly we make your architecture very uniform yes but we do we do get the occasional clothing related that was a good one that was a fun one now so what I wanted to allude to in this story is that for that brand to separate the front end technically you could quite easily do it you just start with a new next or next front end and then you slowly build apis at the same time on that old system and just connect things up right the thing is though Brands like that don't want to do a big bang after two years they need to see constant updates move along with the market newest Tick Tock Trends all the things right and they'd have fashion shows every every season and the things would change sorry you wanted to say something Mark no I was going to say I'll go further than that it's not just Brands like that nobody wants to do a big bang anymore oh okay that's true that's true you know anybody anybody that's been around has had the pain of having to upgrade their old You Know cover system or content management system or whatever the case is and and even people you know I've I've talked to CMOS who are on some of those older systems and even though they really want to move off the fact that that old system is really firmly embedded they want to avoid that big bang as much as possible well yeah it's the time to fail you thing right you need to the Optics matter so much in this and so that's what we essentially this is a few years ago before I joined uniform before it existed even we we built a tiny uniform ourselves the thing is I had to hire 20 people to do it and so what we did is we did a redesign of the whole platform we implemented that redesign on the old pages and every time we built something new we also added it there and then the old site and the new site were living side by side and certain pages took four seconds to load and certain pages took 50 milliseconds to load old and new right but they looked identical so every time there was a slightly new design or a new product or something we would implement it in both and then the new one would take over more and more components of the old one until it was kind of until it ate up the whole old site and that took us about a year but we had a new value every week and the Optics of doing it that way while holding the client's hand essentially and taking them on this journey that worked amazingly well it was just really rough to do that without having a productized DXE right we had to kind of build it out first ourselves yeah so talk about how uniform would would basically solve that problem you know get you to the same end result but with better performance but also not mean that you're having to duplicate content and go through that pain that you went through yeah so I mean I'll paint that picture because in uniform we have something called a project map and in there you lay out your whole URL schematics right home about product overview category a b c and this ABC can be dynamic URLs right so they have URL parameters that basically fetch different types of data so you can set up all your URLs and their wild cards in uniform but not every URL has to point to a composition in uniform that is actually a page that is shown it can also be a placeholder with a redirect so what you would do which you would set up older URLs and the user would hit uniform based on whatever redirects you have you can actually let the home page still go to the old system and then when you would have the about page might be a new one already in uniform and so that would just be redirected to Something in uniform and so that's the first bit right so you can split up where people go through that then this old system that Legacy system that you have you can make that a Content Source into uniform or a data type we like to call this well it's a data source that's the system and the type is the type of thing that you would query from it from products to images to about us blog posts or whatever and so you could just if you needed the same content that was on the old system that was displayed on the old website you might need some product information to show on another page in your new system you would build a whole new front end and just connect to that Legacy API and select which content you need in your new system all in the uniform DXE space so there's no connection to that old system at all in your front-end code your front end just connects to uniform and uniform connects to that old system so what we saw back then when we were building this there's their search engine was really slow but it's one of their most important thing because these type of shoes could never be next to that handbag right so that needed to be really done well and so once this whole site was built it was still using the old search but then because it was so clean and the setup was so easy we could just say you know what all the search now goes to algolia I'm not sure that Jose they might have chosen kovale or some custom solar thing but they were able to relatively easily take that out plug it into the new thing and that search engine now got the data from the old system they were connected so we didn't have to do all new data modeling and mapping in that new system or maybe a little bit to make it more efficient but if you did that in uniform that would be really easy and the most important thing that we should say here is that uniform is not in charge of getting the data out of your old system in it into your search engine and modeling it that's not where uniform is doing uniform is here to show you presentation and that's where the data comes from and that's what it shows so it's all about how something looks where it comes from so it's not data modeling in the back end somehow with you know different complicated queries to make that happen so you still have to do that yourself like this yeah that that makes sense and I think but to your point the value is to marketers and people who are doing that assembly right oh yeah we didn't even talk about the marketers here it's literally I just talked deck but you can now drag and drop with that old data in your new designs with uniform visually across even if you don't add 10 more data sources to it the content editors don't have to know where the data comes from as long as they can just select products and assign it to some Properties or select whatever right you don't have to understand it all yeah so as that relates back to evaluation um I think that's that's the thing that's really key to say is you can have a system like uniform it will you know one work with that old content and then two because of the way things are abstracted you can test different systems and different customer data sources and and start to actually build those things and scaffold those things and if you you know learn and change your decisions halfway down the process you don't have to throw out a whole bunch of of front-end work or or even sort of thinking about the problem you know all of that still exists within uniform and is easily applied to will eventually change your opinion on certain things no matter what happens you will always do that because you are an agile team and you just make decisions fast so if you have something like uniform it's very easy to change these things up but if you don't want to change them up that's also fine because when you choose you choose but then there's all these other lovely things that help you to work more in parallel I think that's the the key here yeah exactly so I think at that we've we've probably discussed everything that we needed to discuss around coming up on time as well so nice we are coming up on time yeah um so a little bit of discussion again you know please download the document that we that we wrote it has a lot of these points in the document uh we have another live stream on headless Creator on next Tuesday we have another live stream you know Tim and I talking a little bit more uniform stuff uh next Thursday so we're trying to do this on a on a bi-weekly Cadence so hopefully more folks uh join us for those future sessions and and add comments uh non-fabric related comments and by the way do is because English is not my native language bi-weekly means every other week right uh bi-weekly is one of those confusing words in English that means either twice a week or uh or every two weeks Tuesday and Thursdays there we go Tuesdays and Thursdays for the coming month this is our space and we're really excited about it yes exactly thank you for pointing out the absurdity of uh of the English of English yes exactly thank you it's part of the part of the problem is that English is very greedy as a language it just steals from other languages and so uh there's uh not a good sense of consistency and rules unlike uh say uh German for example which look we have a really nice comment this time much better not non-fabric related comments not a fabric related I like it all right um cheers everyone and we'll hopefully see you on Tuesday on the atlas Creator stream cheers yes ending broadcast