How Brightspot gives you ultimate flexibility: Future-proofing

How Brightspot gives you ultimate flexibility: Future-proofing
Requires Login
How Brightspot gives you ultimate flexibility: Future-proofing

Learn here what considerations and factors technology leaders need to consider as they make decisions about investing in—and future-proofing—their tech stack.

Key takeaways for future-proofing an organization's tech stack:

  • The realization that you can't predict future changes to your business and need to be able to respond incredibly quickly was expanded by COVID-19
  • Your tech stack now needs to “future-proof” your business by giving you the flexibility to change and adapt rapidly
Transcript

Speaker 1: so the fourth trend and this is, you know, kind of a buzz word, but you know, future proofing and I think you might have used that that term before we hear it a lot and you know, I think the the digital landscape has been changing for a very, very long time and it was changing rapidly. But I think covid really 14, 15 months ago shaped in our minds just how dramatically and quickly things can change overnight, right? Like the the idea that, you know, 15 months ago that your internet for instance would be as important to your your your content business strategy in terms of internal content managing or immediately suddenly remote organization. That that suddenly in a day or a week as important as your external facing content or the idea that live events are now digital and online and we we viscerally all kind of live with that and and are wondering what's the next time the landscape is gonna shift underneath us so quickly and dramatically as a, as a leader of of a development organization. And when you think about making decisions in your tech stack to let you future proof, what does that mean to you? And and and how do your recent and semi recent experiences, how does that kind of shaped how you, how you think about doing that? Um Yeah, I mean, I think, I think the really important things that you can uh that you can think about the future proof are really just making your content accessible to whatever whatever comes next. You know, we don't know what's going to come next. We have a decent idea that the web is going to remain popular for a little while. We hope very long while mobile phones aren't going anywhere. The mobile experience is getting more and more pervasive. Um but you know, there there we don't know what's next, but we do know that the ability to access your content from, from all of those different applications is really important. You don't want to you don't want to be painted into a corner where your content can only be accessed in a in a very strict hierarchical way and it's and it has, you know, it's married to html and there's really no way to get to that data without, without parsing html. Who knows really? I mean html may go away in the in the next few years for all I know. So um you you really want to make sure that your content is is independent from your from your presentation of that content. And I would I would say that bright spot does pretty good job of that. Um you know, again I've mentioned before the is an acronym, this is something that that's just taken care of in bright spot if you have if you model objects in your system and um you know, if you if you model those objects in your in your system then they're saved in the database and you don't have to worry about how they're saved in the database, what that underlying structure looks like. They just they're available to you as those as those objects. Um So as your data model changes, then this is a really important point. As your data model changes your data in the database remains backwards compatible. I mean there's there's work to do, of course, to make it backwards compatible, but but that work is is built into the bright spot workflow. Um So as your data model changes over the years, you know, maybe you have maybe your article model has a single author and you want to decide someday that you're that you want to have multiple authors. Um and some other systems that could be that could be like a whole database schema that needs to be rethought right? But with bright spot, it's not it's not it's not really a big event for us at all. If you have a single author field and you want to turn it into multiple authors, then you just kind of remodel that in your in your java object in your java class and kind of just works. Now you have multiple authors and it's not a it's not really a big deal. You don't have to run a D. D. L. Script or anything like that to change your database schema. Um It's it's something that just kind of rolls out naturally and for those of you who have who have experience rolling out CMS and especially enterprise uh systems that are heavy users have a database like this one is you're going to have that experience and you can probably tell me more stories of of of times when the D D. L. Went wrong and you drop the table or something like that. And those are those that whole class of issue is something that you don't deal with in bright spots, you're really just working with with those objects. And again, it's really all about having that, having access to that content really no matter where you are and um and and what technology is trying to understand that content, it's just it's it's your data model, it's your data and it's available to you. So I think lee that when these terms that we have on the slider, modular content and hybrid Headless I think are are industry terms that speak to a lot of the use cases you've been talking about before. But modular content really would be the I think the idea that as you were describing the no code and low code solutions before a piece of content that you have modeled and is included in a website, let's say that that uses one of bright spots themes or one or more websites or applications that are or maybe even in headless implementations. But then along comes one of these new endpoints that you haven't thought about yet. Right. Modular content essentially allows you to feel comfortable that whatever, that new experiences that you create, that that same piece of content is available and you can reuse it in that new in that new endpoint with no disruptive, no disruption to your tech stack or or your editors workflows. Right, Right. That's exactly right. And it's important to be able to do that because you, you know, you're you're you don't want to repeat yourself when you're when you're when you have important content that's gone through a workflow and has been approved by maybe the legal team or the the the the medical review board or something like that. I mean there there are those workflows that really have. Um and every business isn't like the support, but some businesses are and we want to make sure that we support that. Um you know, once content has been approved and it goes into this into the CMS, you're gonna want to reuse that content, you're not gonna want to um you're not gonna want to try to send it back through the workflow just because you have launched a new mobile app, you want to use the content that's already been approved and you want to use that multiple places at the same time. If it changes and if it changes because, you know, the copyright year changes or something like that, then you want to make sure that that's distributed out to all of those endpoints without having to again repeat yourself and do sort of this, this tedious, find and replace over thousands of pieces of content with modular content you have um you it's up to you to choose when you're repeating yourself and when you're referring to content that already exists and the hybrid headless term too. I think that's a cool marketing term that really describes what you've already been describing I think with regards to bright spot, right. The idea that you can use the headless implementation for one or more pieces of content while at the same time using the no and low code solutions you described and essentially give your organization the flexibility to pick and choose which implementation is most appropriate to the specific business problem that they're trying to solve rather than it being sort of a binary headless all in or you know, no code, low code all in kind of choice. Right. Right. Exactly. Right. If you have, again, if you have a friend and team that's comfortable with with graph QL or or with, you know, our other api endpoints rest or Jason endpoint, then you can certainly start developing developing uh using those endpoints right away without having to throw away the entire site and say, okay, we're headless. Now. Now what we're starting from zero, it doesn't work that way. You have a working site. You want to add some some headless interactivity through it. You can certainly do that. Or again power another app such as a mobile app or O T T or anything else. So I think those two terms for me were pretty easy as a non developer to kind of translate back into the, some of the comments you were making. But extensible architecture. I think when you think about those terms, is there a use case or two are sort of an example of how when when Bright spot describes its extensible architecture exactly what that means or maybe an example of how that's played out on something you've worked on recently. Sure. You know, it's by extensible architecture really we mean that um at its core rice but is a java application, you know, it's a, it's a, it's a server side job application. If there are um, if there's an integration that you need to do that that interacts with the another system. Um or if you want to create a whole new api endpoint, that's not graph QL and it's not rest and you can do that in java, then you can do it. There's no, there's not really, there's not really any limitation as to what our platform will or won't support. Um, it's, it's just a matter of um, again, putting the right resources in the right place and, and um, and just building it now, if you don't want to build, if you're not interested in java development, you're not and you don't need to do that back end, back end development then you can use our front end api s to, to really make a bright spot part of your overall architecture, without having to say um you know, without without having bright spot be the only part of your overall enterprise architecture. Um I think that the bigger the bigger customers we have, um they're not just running bright spot. Right. Bright spot isn't the only piece of technology in their system, in their enterprise architecture. They have other systems running other, they're responsible for other parts of the business. Um and bright spots ability to to interface with those systems and um and integrate with those systems is really powerful because you can take the, you can bring the data to where people are and without having to log into a lot of different systems. You know, maybe maybe you do want to log into a bunch of different systems but maybe you want to um maybe you have a calendar application on another system and you want to present that on your internet in the internet powered by bright spot. That's that's a relatively straightforward integration that we could do. It's just a matter of again, you know, building that out whether that's on the front end or the back end, we have lots of options as to how we might accomplish something like that. And even the knock biggest customers that we have in most cases there's probably a Martek integration and analytics translations personalization. There's probably a number of integrations or extensions to their platform that that even a more modestly sized organization might require. Right, sure, absolutely. And some of those integrations are are something that can just be configured in the CMS without having to have any developer developer involvement. Um you know if you if it's something like a form collection or something like that, a contact form collection, you can just go and log into the CMS and configure that um if you have an integration with say male champ and you want to you just want to collect subscribers on your on your page or on your website um that's something that you can just configure the male chimp integration endpoint and set up a forum and bright spot and that would be something that just that that you really don't need any developer support at all for that but but there are some things that you would need, you know back to the kind of levels of customization conversation there there are some things that you would need um light developer input to try to accomplish different things and and we just we just we just have the ability to um or bright spot has the ability to to provide those customization entry points depending on your um your resources and your level of effort that you're willing to put in