COE Best Practices: Should I use a service account?

[DerekHurley]

I want to find out what are the best practices for setting up a centre of excellence (COE). Should I use a service account, different from my personal account, for our COE? For importing of all the COE starter kit components and then use of these. As far as I understand this has a few benefits:

1. You can give the service account all needed permissions, so none of the flows, canvas apps, etc will run into any issues.
2. The COE will not be tied to an individual users account in case they leave the business 

Does anyone have experience with this and what would you say is the best practice, and why?

Thanks

[jlindstrom]

@jhall_IUH  

---

@jhall_IUH wrote:

this is where I start to wonder if I am talking to a liar, an idiot, or someone who is blind. 

---

 Please leave personal insults out of your comments.

[jhall_IUH]

@jlindstrom I saw the Dataflex announcement.  I even wrote about it.

As an example for what I have designed our COE around, I had an emergency request for an application to calculate blood sugar ratios for Covid patients hit my desk at 4:30pm last Thursday.  While other Architects were arguing about how/where/why this might get built (before the following Monday), one of them fwd'd me the request, I wrote it, and published it out a fully functional version before 5PM that day.  THAT, is what building out a work stream to focus on rapid deployments gets you.  And while it isn't the solution to all problems, neither is building toward a storing optimized data in a RDB.

The argument of needing a structured data store, management, supportability, etc. are all valid...to a point.  But I use the analogy quite often of:

• why don't we all drive Semi-trucks? 
• Because we don't need all of that overhead. 
• How are you going to move your entire home in your Yaris?
• I don't and I won't.  I'll hire movers.

These arguments around scalability and even "robust RDB" are only relevant when they become so.  The promise of low/no code is that you can potentially divorce your application from the constraints of data management to allow for deployment while optimized data storage is still in progress.  The applications designed during the Covid crisis are not (for the most part) storing data permanently within these containers.  These are transitionary applications designed to quickly adapt to daily changing workflows while ultimately (somewhere down the line) dumping this data into some other legacy repository.  The entire methodology of Model applications only seems to make sense when you have a highly static process within an Enterprise and are prepared to plan a rollout over the next year.

Why would I even worry about discussing data optimization on an application that may or may not ever roll out to users?  Or an application that impacts 10-12 users, or one that impacts the entire enterprise, but used very sporadically?  Why force a conversation about scalability before it is necessary?  That's the entire promise of these toolsets is that we can deploy on limited staff resources, then scale where needed.

Our applications all start w/ simple JSON storage (written by BAs).  As things move forward, we let the Data Analysts drive what components should be pulled out into searchable consumable content.  When we reach a level of maturity with that, we adapt the application (either BAs or Developers) to now write to the data store in a more formalized manner.  And finally, in almost every scenario, we copy that data off to other legacy platforms (by DBAs) for long term storage before removing it from our interim workflow data storage.  We always retain the possibility that we'll write data directly to a RDB, but it is a journey of choices, not a predetermined destination.

This allows deployment IN HOURS.  To walk into a meeting with an application loosely framed up before ever sitting down w/ the business.  To make changes during the meeting and still have a functional application.  It also drastically lowers the technical capability of someone who writes UI applications while giving clear hand-offs to more specialized staff.

THIS is the promise of low/no code near-term.  Focusing on Dataflex Pro/CDS is Microsoft shooting two moves ahead toward some POSSIBLE future state that also slows down deployment TODAY.  I have a solid and reliable deployment model w/ an existing .NET development team (of which I am a part).  I can turn the crank on that and deploy applications w/ full processes integrated into DevOps and planned deployments.  To return to my earlier analogy, I have a fleet of trucks and drivers at my disposal.

I PERSONALLY don't need to solve for highly reliable and scalable solutions immediately, because

• that need is not as large as one might think
• we already have solutions in place 

I wouldn't dare tell my team to abandon .NET and to start using these tools instead.  What they do works and while it is slow, it is reliable.

But those kind of projects take a great deal of meetings/planning to even justify work starting.  Lots of meetings to talk about whether or not we, as the kings of technology, will allow these business peasants to acquire our expertise.  They must justify their need for our time, because our time is limited.  This creates a barrier through which many projects never pass. Again, to return to my analogy, the business user just needs to drive to work.

So, after a request is denied by these slow formal processes, what happens to the need that caused the original request to be made?  Did it disappear?  Did the business go back and say "aww shucks, you're right, we didn't really plan that out well, we'll think about it for the next year while we continue to suffer through X"?  No, they hired a vendor, they built it themselves in some 3rd party tool, or (far too often) in Excel.  Shadow IT is born.

Changing the delivery model to enable immediate delivery solves for X and gives these kinds of requests a path through which they can easily pass.  When we throw up the barriers of traditional development and tie it to those same concerns, we enable the same bad behavior.

Low/No code is the promise that we can take on Shadow IT head-on.  I would much rather be having a conversation w/ someone who built out an application for 10k simultaneous PowerApps users trying to query a SharePoint list than to be having a conversation with an outside vendor to see if/where their code is, what it was written in, how in the world we'll support that, etc.  By enabling less-bad behavior, we solve for Shadow-IT and can build the processes to actively encourage better behavior (approaching good even) over time.

And the "personal comment" wasn't one, I was stating that I was reflecting on my own internal reaction for when I perceive someone is in denial of facts.  Others can follow along the path toward Microsoft's preferred destination.  Making a choice different from me doesn't make you wrong.  But if you are basing that choice upon denying factual information, then that's where the discussion is less about the content and more about your selective perception of the evidence before you.  Denying that Microsoft has a clear path paved toward the Dataflex Pro/CDS data store and is actively marketing it at all points along the way as a revenue stream is denying reality.

[jlindstrom]

None of us have been arguing that everybody should use CDS for all apps. My suggestion was to have at least one full licensed user and one CDS environment so you can run the COE starter kit. It would be rediculous to suggest that CDS should be used for every app (nobody is) just like it would be rediculous -to say that everything should be written on Excel and Sharepoint. Fit for purpose and use the right tool for the job.

It is all in your perspective--if you think the value of your apps is low, then CDS is expensive. If your apps are more critical, compared to using bigger more expensive applications like Dynamics or Salesforce on an enterprise platform for $10/user is a bargain.

[jlindstrom]

As to your scenario about blood sugar. That is a really good example. Seriously that is an amazing use case. Agree you don't have time to do a big design before building that scenario if you need it quickly.

But that doesn't mean that's the permanent solution for the issue. The building is on fire, we need to put the fire out. But once the fire is out it's important to think about the long term solution and ensure that it will scale. The Band-aid isn't always the best permanent solution

[jhall_IUH]

@jlindstrom And that's kind of where we're talking past each other.  I don't begrudge the usage of the CDS where justified.  I don't specifically begrudge the costs of the COE starter kit for a handful of CDS-enabled licenses.  What I started the point around was that Microsoft does all of these things built upon the CDS when it isn't required.  As is the case of the COE Starter Kit.

They're greasing the pole very actively and obviously.  As someone who is very aware of this, it actively slows adoption for our organization, because all of leadership is afraid of if/when the bill will arrive w/o a clearly attributable benefit.  I must constantly convince people to adopt the platform, while also actively trying to stop them from adopting it in the way Microsoft is pitching it.

[jlindstrom]

You are saying that you don't need scalability because you have a staff of .net developers so you are not using the platform for those solutions. That's fine, but not everybody has that. Nobody is taking away the tools you have now or saying that you have to use CDS. Just because you don't want to use the platform for that, doesn't mean other people don't. 

I don't get why you are so offended by CDS, if you don't need it. To flourish this platform needs to be viable for more mission critical apps and low code apps.

[jlindstrom]

but cds is central to the COE> You need a database to store your app entity, etc, as well as the more enterprise grade governance components. Where would you store that stuff?

[jhall_IUH]

@jlindstrom Yes, the blood sugar one is but one of many that occurred during this period.  Many others remain.

Primarily, my point was that Microsoft's version of using data models to build out apps fits more w/ supplanting traditional development workstreams vs. accommodating these kinds of small applications and/or emergency applications.  What I've adapted around is to allow a progressive deployment that doesn't force restrictive assumptions at the start.  There is no doubt that other applications required enhancement (e.g. a Nurse skills-gathering and volunteer submittal for accepting deployment in Covid-related care areas which rolled out to 8k nurses in the span of a week) and ultimately a better data store.  But in these scenarios it still allows for immediately deployment while the data side of things matures as the needs escalate.  

Many of the policies/restrictions around traditional development are to protect developers (a scarce resource).  When we lower the bar for who can be "a developer" on these kinds of platforms, those assumptions change.

[jhall_IUH]

@jlindstrom Per COE data storage, as I stated, we're a .NET development team.  They (and I) find it fairly annoying that we cannot (for free) plug PowerApps into web services hosted in Azure and/or Azure SQL data stores that they are maintaining for other projects.  This is already a path they are following to write Microsoft checks, why suddenly pay to access something we're already paying for in some other way?  Why the unique licensing model for an organization who already bought into the ecosystem?

I understand Microsoft's reasoning here.  I recognize that they want to pitch this to orgs w/o formalized Dev teams/processes.  By lowering the bar for staffing (and subsequent costs of said staff), they want their cut of the savings.  

If the COE kit included spinning up a data model within an existing Azure SQL instance and no licensing hit beyond usage, then my team would just enable that tomorrow w/o pushback.  It would be an easy sales pitch. 

Even though that would likely wind up more expensive than the per-user licensing for what we'd do at that scale.  It is more that it is an identical model/method to what they use for other data storage solutions across the enterprise.  

[jlindstrom]

But the licensing requirements to use power apps with azure sql are the same as cds. I don’t get your point. Storage capacity? But the storage capacity required for coe starter kit are small and would fit within your base allotment. So what is the point? You can’t use azure sql with office seeded power apps.