Archive for the ‘Enterprise Architecture’ Category

“A COE is “best practices and lessons learned standardized and codified into a framework and repeatable methodology.” – Me

COE Operating Model

Third time in seven days at two conferences that I attended a breakout session on BPM Centers of Excellence. COEs are a subject of interest to me in that I’ve done it four times in the past eight years and it is (should be) about sharing the wealth (knowledge, assets). First time was for a large Southeast financial as an LOB solutions architect protesting the fact that the COE wasn’t getting me the things I needed. Second time for a large bank in the Northeast, the infra guys loved me because, as the lead architect, I kept bad apps from getting into production (the #1 goal in my opinion). Third go ’round I helped spin up the community forum for a large insurer in the Northeast, submitting an operational model for their COE. Latest go ’round is with, once again, a large financial. Supposedly there’s a COE out there somewhere, but it’s pretty ethereal, finding standards, assets, assistance; we’ll talk ‘visibity’ later.

Anywayz, back to AIG’s “AIG Leverages Their Center of Excellence for Strategic Advantage” session a week ago yesterday at PegaWORLD 2014. They use Forrester’s definition of a COE

  • delivery assurance (code reviews, design reviews)
  • resources and skills
  • technology and architecture (common platform)
  • QA
  • infrastructure

and implemented their COE because they had a lot of everything – apps, support groups, partners, platforms. Though they’ve had Pega for a while they implemented their COE with the mission of thought leadership, to accelerate projects, mitigate risks and function as vendor liaison. In-flight for about 1.5 years, they’re running a centralized model and coming out of the gate were, are working on managing resources, frameworks, integrations with centralized repositories on the way down the road. Standard benefits realized on efficiencies, standards, standardized estimating process, re-use, having specialist, driving agile use and achieving resourcing flexibility. Like a lot of people, they’re still working on Agile and did acknowledge they’re still Waterfall within the org. Another good thing they’ve done, IMHO, is implement a community forum (more on that later).

Some other items of note:

  • They use Pega cloud for their sandbox, dev environments and provision quickly to new LOB development teams.
  • Enterprise Architecture and an EA in the role of COE leadership and a member of the core COE team is present; that also is important.
  • Like a lot of people in the Pega world they’ve built a core framework on top of the Pega base.

On the subject of “lessons learned,” appreciating their candor, they did pony up and acknowledge that, like a lot of people that funding at the corporate or project level is an issue. About 40% of their funding comes from the business units (resource allocation). Other lessons learned:

  1. Pega expertise to build guardrail-compliant BPM apps
  2. Alignment with Enterprise Architecture
  3. Central repository and structure
  4. Management support (always key)
  5. They did good on documentation but fell down on putting it out there and visible on a central repository.

The senior information officer hedged when I asked the pointed question about what did they do if any of the dev teams nuked their sandbox, what did they do with a “I call Pega,” but I myself in the past have just reverted the VM (on premise or otherwise) to a previous snapshot and said “Hope you have your stuff backed up.”


Later Monday afternoon there was a panel session with Cisco, JPMC, BNY Mellon and Jabil Circuits talking about their Pega BPM COEs. Five to ten minutes per individual with a short deck each and backgrounders on their COEs, my main grouse about this was there wasn’t enough time left at the end to ask questions. Interestingly enough, just as with the morning session, there were other people from other orgs’ COEs in the audience and I wish a more extensive dialogue could have occurred. If you’re interested, Pega has spun up on on-going forum and as soon as I learn what the true e-mail address for requesting participation is (it’s not PegaWORLD2014COE@pega.com) I’ll pass it on.


Flash forward a week. Last, but not least, Scott Simmons of IBM talking about COEs as well (does Big Blue still call them competency centers?). Scott’s deck demonstrated he’s been around the block a time or two and I was mostly on board with the practical advice he was giving. I did disagree with him on his three most important features of a COE. He stated it was re-usable assets, I maintain it’s governance. Why? Me, myself and I, applications/solutions or systems/enterprise architecture, in the trenches, my number one goal is to keep a bad app from getting into prod.

I’ll look at Scott’s deck later, but interestingly enough he was one of several individuals with some link to Colorado who are here at the conference.


So what’s the moral of your story Mr. Peabody?

  1. It’s about expertise, period, plain and simple.
  2. For me, it’s all about the governance piece. If you don’t have the empowerment, the authorization, the… “teeth,” there’s not much point.

What’s next?




Read Full Post »

“One architecture to rule them all. One architecture to find them. One architecture to bring them all and in the machine room bind them.”


This post is not so much a redux of my very first blog post, but rather a continuation of that. In fact, this post will be the first of an on-going series regarding reference architectures, architectural strategies and long-term roadmaps within the context of ECM and BPM both. The series will drop from 20,000′ to 200′ as I descend through the cloud on a large technical architecture recommendation and roadmap for a client.  Without belaboring the efforts delineated in that first post and their respective outcomes, this one will take everything I knew up to that point, since that point and beyond as well. I’m going to stretch on this one.

Everything I’ve observed, learned, done in the past twenty years in this space and project it (yes, believe it, you heard, read it here first)  three years forward. Agreed, that’s a long time in today’s world. The issue for this “technical recommendation” though will not be technology, it will be execution. The roadmap will be three years in duration because that will be the degree of effort required to effect it. And this time I have the juice, the influence and the appropriate ears to see it through.

Beyond the initial table of contents screen shot above, this will actually be one of three artifacts I produce for this client, the other one being a Lunch ‘n Learn curriculum I will draft delineating the “how” of everything in the ref arch as well as a third on some of the tools I will be using to blow out portions of the technical recommendation (e.g. – the ontology and the taxonomy).

In short, this thing is going to be a freaking masterpiece. It hasn’t been explicitly mandated, but it has been tacitly requested within the scope of my effort and participation with this client. They’re big, huge in fact; and so will this be as well. As for myself it will be the progenitor to multiple case studies and, longer term, one service offering and one commercial, shrink-wrapped product I’ve long dreamt of, want to build and sell.

So get ready kids. Twenty years in the making, we’re going to get down in the weeds on this and go way beyond the ‘101’ level to infinity and beyond. Should be fun, hope you enjoy my trials, tribulations, angst and tenacity all.

Oh yeah, I’m going to write all three in three months. I’ve got other schtuff to do as well.

So what’s the moral of your story Mr. Peabody?

Never stop trying, never stop learning, always try to do better than the last time.

Read Full Post »