Here at Appian we're really excited to have released our data fabric security feature earlier this year. If you're not sure what that is, you're in good company. Even our parents just look at us blankly before saying "that's nice, dear" and changing the subject. Someone who doesn't love us unconditionally might be more skeptical.
"What on earth does 'data fabric security' mean? Are you just jamming buzzwords together?"
Honestly, this is very cool stuff, but no one had done it before, so we had to invent a term combining "low-code" with "data security" to describe it. This is the difference between science and engineering: when a scientist figures out something no one knew before, they get a Nobel prize. When an engineer does something no one's done before, they have an excruciating meeting with the marketing department about branding. So forget about the terminology. I'll walk you through this and why we're so excited about it.
We're talking about security, and the simplest form of security is the humble access control list. This is like the bouncer at a club. I know, developing enterprise software and nightlife don't exactly go hand and hand, but we all know the concept of a big guy standing outside a nightclub and not letting anyone in who's not on the list.
The software equivalent of a bouncer might be a list of people who are allowed to access part of a website. Now if you're saying, I don't need Appian for this, this is simple to implement…you're right, if that's really all you need. But it's not so simple, is it? For one thing, how do you update the list? Is it compiled into the code? Do we have to fire this bouncer, hire a new one, and train them with a different list? Sorry, I guess the analogy's pretty strained, but I'm trying to find the equivalent for recompiling code with a new embedded list of people every time you want to tweak it.
"See, in this analogy, your paper list is just computer code, and you yourself are like an application server. Or maybe a microservice. Wait…don't…ow…okay, okay! Sorry, you're not micro. You're a macroservice! A one-man monolith!"
So you store the list of people in a database and have some kind of administration interface to update it. But what if there's not just one nightclub, there's a lot of them. It's a nightclub…chain. Like Starbucks, but for nightclubs? To make sure the latest TikTok celebrity can get in, even though no one had heard of them before fifteen minutes ago, you don't want to have to change the list at each location. You want to change it in just one place and have it affect all of them.
And you might have a separate list of people who can access the VIP room, but to get there they have to get into the club in the first place, so everyone on the VIP list needs to be on the club entry list too. So now you have nested groups of people. If we're talking about a big company and not a small business like a nightclub, there could be many thousands of these groups in a complex nesting hierarchy.
Nested group security is a good start.
The good news is Appian has a Group abstraction that handles all of this, but that's old good news. We've had that for years. So although this nested group stuff is already more complicated than someone might expect, we haven't even gotten to the real difficulties with securing data yet. That was just context.
Nested group security is nice, but what if you want to secure the safe in the back of the nightclub? Only the manager is trusted enough to access the money there. If the VIP list is more privileged than the entry list, then this is even more privileged. So maybe it's just another nested group? Could be.
Trouble is, we're working for the Starbucks of nightclubs here. There's one on every corner. So sure, the manager can access the safe at their location, but they shouldn't be able to go across town and make their rival for promotion to regional VP look bad by stealing from their safe! We want each manager to be able to access only the safe at their location.
Hmm. So maybe there's a group for each nightclub? How many nightclubs were there again? In 2021, Starbucks had over 33,000 locations. This is way too many groups. It's also probably too many nightclubs, if we're being honest. Maybe we're guilty of over-expanding, but maybe the pandemic has made people really want to get out of the house.
How is it possible to track change across such a vast database?
To keep track of all these locations, our nightclub chain's IT department probably has a database table called something like "locations" and they each have a unique id. Maybe there's a field in that table for "manager". At this point, what a lot of people do is, whenever the manager changes, they update the group or access control list for the safe in the back. And that works okay…if you found all the places where the manager changes! If you missed one, get ready for bugs.
And not just any bugs: security bugs. Oops! The manager you fired for stealing still has access to the safe, they took all the money, and now you're in the CIO's office trying to explain that no, you didn't intend for this to happen, it's just that you made sure the normal offboarding code updated the safe security, but you forgot firing people goes down a different path.
Compliance should not be an assumption.
Maybe you're shaking your head. I wouldn't forget that, you're thinking. My long experience in software development and subject matter expertise in multinational nightclubs means I would remember, you're thinking. Lots of turnover at these nightclubs, everyone in the biz knows that. All right, fine. I've only been to a nightclub, like, twice myself. I was a stereotypical computer science major, all right? But okay, you're an expert and of course you don't make the mistake. What about the new person you hire six months later who sits down and starts working on a feature for helping employees transfer between locations? They're a stereotypical computer science major like me, they don't know anything about nightclubs or the particular set of business and IT processes that have accreted at your firm. They're definitely going to screw this up; the only question is whether you'll catch it before it's too late.
And this isn't some special case. There's tons of things like this in enterprise applications. I assume most nightclubs don't have tons of safes, but we aren't really talking about nightclubs, are we? Medium to large companies have a ton of sensitive information: customers, contracts, sales prospects, peer reviews, HR complaints, and financial results are just some of the many things you want to keep to some sort of need-to-know basis.
Introducing a better way of managing data fabric security.
Fortunately, Appian has a better way of handling all this. Our data fabric features let you secure data based on fields. What does that mean? Well, I think we've more than exhausted the whole nightclub analogy, so let's say you're building a case management system for a customer support desk. Unhappy customers contact you by phone, email, and seventeen different social media platforms to get assistance. Maybe they thought they should be on the list but aren't, maybe the music's too loud, maybe it's not nearly loud enough, maybe they think the drink prices are scandalous…yeah, I lied, we're still working for the world's first multinational nightclub chain.
So who should be able to view one of these support cases? Not just anyone! You wouldn't want it leaking to the press that a hugely famous Youtuber sent you an angry Twitter DM about how your drink menu sucks, even if no one over the age of twenty-three has heard of them. But certainly the assigned support person needs to be able to see it so they can communicate with whatever member of this person's entourage is stuck with the job of complaining to you in their name. The same problem we discussed with the manager applies here, but even more so: if there's fifty cases per nightclub, we're looking at 1.6 million cases.
[ Interested in learning more about data fabric security? Contact our team for more information today. ]
So each case has fields like title and customer. It's also got a field for the support person who's assigned. What Appian does is let you base visibility of this row of data, the specific case, on a rule that refers to the assignee field.
This means whenever you update the assignee, there's nothing to remember, the access updates immediately as well. And although we're talking about data security, because Appian's interfaces are built on top of our data abstraction, this percolates outward to interfaces as well. Everything moves with the data. Even that brand-new developer can't screw this up.
But there's even more to this. What about the nightclub manager? They should be able to see cases for their location, but not for others. We could put a manager field on every case, but then we're duplicating stuff again. When the manager of a location changes, we have to always remember to find all the support cases for that location and update each one's manager. Relational data to the rescue! We can define this security rule based on the case's location's manager. Great!
Maybe there's also a regional VP who should see it? No problem. We can say the case's nightclub's region's VP can see it too. All this without writing a line of code, coming up with a SQL query, or duplicating any configurations. It's easy to create and easy to verify or change later, even if someone else set it up.
As I mentioned before, this extends out to interfaces without further work. Even if there are many distinct applications showing some aspect of this information on dozens of different screens, they'll all respect these security rules. Even reports showing charts of aggregated data will factor it in!
All well and good, but when we're talking data, we have to think about performance as well. If you've got any relational database experience, you're probably frowning right now. "No code, you say? You're going to have to put a big asterisk on that. Maybe performance tuning isn't technically code, but it's just as hard. Maybe harder, judging by how many programmers I've seen fail to optimize their tables and queries." And that's a good point. Relational data like this is powerful and intuitive, but there's always been a heavy burden for developers and/or database administrators to work hard to keep things running well. When the regional VP sits down and wants to see a list of support cases in their region, they don't want to wait thirty seconds for it to come up!
Synced data capabilities speed up the process.
But when Appian says "low-code", we don't just mean literal code, we mean everything that goes with it, and that includes arcane arts like performance tuning. With Appian's synced data, you don't have to put indices on columns, you don't have to optimize your query, and you don't have to worry about how many joins are going to happen and in what order. You just say what you want, and Appian makes it happen quickly.
To demonstrate this, say we have 1.6 million cases tied to thirty-three thousand nightclubs. Sometimes performance can be tied to visible rows, so to be comprehensive, we loaded the first twenty rows, sorted by time, as a support case assignee who can only see a few, as a regional VP who can see a few hundred, and as an executive who can see almost everything. Here's the results:
Again, that was without any optimization. All we did was tell Appian which fields on which related rows to use for security. It took about 2 minutes to configure.
By the way, here's the times for that report, which benefits not just from our data fabric technology but also from automatic parallelization, a whole other awesome Appian feature we don't have time to get into:
Now imagine what you'd have to do to make this work without Appian: databases, indices, materialized views, caches. It would take ages, and that's assuming you have the skills to make it happen at all. Fortunately, teams of amazing Appian engineers have worked for collective decades creating innovative data technology only available in our platform. Thanks to all their hard work, you can get incredible things done in a minute or two. That's the power of Appian's low-code platform and why we're so excited about this.
Applying data fabric security features to your enterprise.
I've never worked to automate operations for a multinational nightclub company, but if I ever do, I know I'm going to want Appian to help me do it. And whatever industry any other company might be in, the truth is, it has the same problems as our multinational nightclub chain. Well, not all the same problems. Hopefully the bathrooms are in much better shape. But we've seen companies struggling with data security challenges in industries like finance, pharmaceuticals, government, energy, and really I could keep going--every industry deals with this--but I'm trying to wrap up this post.
That's why Appian has happy customers in every conceivable line of work. Our low-code platform has answers for the challenges every business struggles with. Data fabric security is just one small part of our platform, but this is long enough already so we'll leave the rest for another time.
If you're interested in learning more about how you can accelerate your business with a low-code platform, download our Ultimate Low-Code Buyer's Guide.
