Spectrum Technology Platform

In software development, many teams (including ours) follow an Agile development methodology. A retrospective represents one of the most useful Agile practices. Teams meet periodically, to hold a retrospective meeting. Here, teams evaluate what is working well in their project, or what they wish to do differently in the future. In the spirit of a retrospective, I want to solicit discussion from both clients and partners working with Spectrum, as well as PB members of this community. 

For those clients and partners who have implemented a solution with Spectrum, what is the one thing you wish you had known, or done differently, before starting the project? 

And likewise for PB folks, what is one thing you want someone to know before they get started with Spectrum?

------------------------------
Brian Casteel
VP, Engineering
Austin, Texas
------------------------------

Hi Brian,

Being a Certified Scrum Master, Retrospective is one of my favorite ceremonies in Scrum where we, as a team, get an opportunity to know what we did well and how can we improve. I really like your idea to use same practices here as well :)

From my experience, when I started learning Spectrum, I referred to lot of Spectrum documentation, Knowledge base articles. Thankfully now we have community and there is lot of learning and interactions which helps to understand Spectrum better.

------------------------------
Ruchi Mishra
Pitney Bowes Australia Pty Ltd
Melbourne
------------------------------

Another thought on this thread... Many clients and users do this - and many still do not. When implementing a Spectrum-based solution, we recommend maintaining a separate deployment apart from production. This is typically called a sandbox, dev, or pre-prod deployment. It basically serves as a place to develop and test data flows and services without interfering with the production mission-critical Spectrum deployment. 

Pre-prod deployments are hugely useful when tuning a Spectrum deployment. For example, if tuning the match rules in a Spectrum job, it's best to tune in a pre-prod deployment. Then when the desired results are achieved, promote the new match rules to the production instance. 

Additionally, pre-prod deployments are useful when troubleshooting issues with Tech Support, Engineering, or Professional Services. 

Again, many clients do maintain a pre-prod sandbox deployment. And we've seen many who do not. So, we strongly encourage this as a best practice when preparing a solution with Spectrum. 


------------------------------
Brian Casteel
VP, Engineering
Austin, Texas
------------------------------

Hi Brian.
Interesting Topic.
I work in project for a large insurance company in europe.
We implement Spectrum as a Master Data Management System.
Most of the banks and insurance companies I know have a 3 stages deployment structure.
One system for development, one for testing and one for the productive operation.
Unfortunately Spectrum is not very handy for this.
There is no deployement automation. I always have to export and import the flows on the different systems.
I cannot export the folder structure from my Enterprise Designer from one system to another.
I have to activate reimported flows manually. I could easely extend the list.
How do you and other customers deal with this problems?

------------------------------
Maximilian Zurek
ADWEKO Consulting GmbH
Walldorf/Baden
------------------------------

Original Message:
Sent: 07-03-2019 08:20
From: Brian Casteel
Subject: What is the one thing you wish you'd known?

Another thought on this thread... Many clients and users do this - and many still do not. When implementing a Spectrum-based solution, we recommend maintaining a separate deployment apart from production. This is typically called a sandbox, dev, or pre-prod deployment. It basically serves as a place to develop and test data flows and services without interfering with the production mission-critical Spectrum deployment.

Pre-prod deployments are hugely useful when tuning a Spectrum deployment. For example, if tuning the match rules in a Spectrum job, it's best to tune in a pre-prod deployment. Then when the desired results are achieved, promote the new match rules to the production instance.

Additionally, pre-prod deployments are useful when troubleshooting issues with Tech Support, Engineering, or Professional Services.

Again, many clients do maintain a pre-prod sandbox deployment. And we've seen many who do not. So, we strongly encourage this as a best practice when preparing a solution with Spectrum.


------------------------------
Brian Casteel
VP, Engineering
Austin, Texas
------------------------------

Hi Maximillian - have you looked Spectrum's Administration Utility (commonly referred to as the CLI or Command Line Interface)?

Here are examples of a couple of relevant commands.  You can create scripts that automate many tasks.  Let us know what you think, or if you have looked at this prior and it is missing the mark in some way.

https://support.pb.com/help/spectrum/18.2/en/webhelp/AdministrationGuide-WebUI/index.html#AdministrationGuide/source/AdministrationUtility/dataflows_exportdataflow.html

https://support.pb.com/help/spectrum/18.2/en/webhelp/AdministrationGuide-WebUI/index.html#AdministrationGuide/source/AdministrationUtility/dataflows_importdataflow.html

------------------------------
Aaron Wallace
Knowledge Community Shared Account
Shelton CT
------------------------------

Original Message:
Sent: 07-04-2019 03:06
From: Maximilian Zurek
Subject: What is the one thing you wish you'd known?

Hi Brian.
Interesting Topic.
I work in project for a large insurance company in europe.
We implement Spectrum as a Master Data Management System.
Most of the banks and insurance companies I know have a 3 stages deployment structure.
One system for development, one for testing and one for the productive operation.
Unfortunately Spectrum is not very handy for this.
There is no deployement automation. I always have to export and import the flows on the different systems.
I cannot export the folder structure from my Enterprise Designer from one system to another.
I have to activate reimported flows manually. I could easely extend the list.
How do you and other customers deal with this problems?

------------------------------
Maximilian Zurek
ADWEKO Consulting GmbH
Walldorf/Baden
------------------------------


Original Message:
Sent: 07-03-2019 08:20
From: Brian Casteel
Subject: What is the one thing you wish you'd known?

Another thought on this thread... Many clients and users do this - and many still do not. When implementing a Spectrum-based solution, we recommend maintaining a separate deployment apart from production. This is typically called a sandbox, dev, or pre-prod deployment. It basically serves as a place to develop and test data flows and services without interfering with the production mission-critical Spectrum deployment.

Pre-prod deployments are hugely useful when tuning a Spectrum deployment. For example, if tuning the match rules in a Spectrum job, it's best to tune in a pre-prod deployment. Then when the desired results are achieved, promote the new match rules to the production instance.

Additionally, pre-prod deployments are useful when troubleshooting issues with Tech Support, Engineering, or Professional Services.

Again, many clients do maintain a pre-prod sandbox deployment. And we've seen many who do not. So, we strongly encourage this as a best practice when preparing a solution with Spectrum.


------------------------------
Brian Casteel
VP, Engineering
Austin, Texas

Hi Maximillian,

Spectrum OnDemand is structured in a 3-level similar to how you described and we automate service deployment through the Dev -> Testing -> Production levels using the CLI that Aaron mentioned.

We prohibit the manual editing of any flows in Testing and Production environment (changes must always start in Dev) so we haven't found the lack of folder hierarchy necessary for Staging and Production.

In Spectrum, the folder heirarchy is probably best thought of as a tag as there can only be one dataflow of a particular name regardless of folder hierarchy.

I would be very interested in learning more about your list of issues you face with deployments.

Regards,

------------------------------
Jason Brown
PITNEY BOWES SOFTWARE, INC
United States
------------------------------

Original Message:
Sent: 07-04-2019 03:06
From: Maximilian Zurek
Subject: What is the one thing you wish you'd known?

Hi Brian.
Interesting Topic.
I work in project for a large insurance company in europe.
We implement Spectrum as a Master Data Management System.
Most of the banks and insurance companies I know have a 3 stages deployment structure.
One system for development, one for testing and one for the productive operation.
Unfortunately Spectrum is not very handy for this.
There is no deployement automation. I always have to export and import the flows on the different systems.
I cannot export the folder structure from my Enterprise Designer from one system to another.
I have to activate reimported flows manually. I could easely extend the list.
How do you and other customers deal with this problems?

------------------------------
Maximilian Zurek
ADWEKO Consulting GmbH
Walldorf/Baden
------------------------------


Original Message:
Sent: 07-03-2019 08:20
From: Brian Casteel
Subject: What is the one thing you wish you'd known?

Another thought on this thread... Many clients and users do this - and many still do not. When implementing a Spectrum-based solution, we recommend maintaining a separate deployment apart from production. This is typically called a sandbox, dev, or pre-prod deployment. It basically serves as a place to develop and test data flows and services without interfering with the production mission-critical Spectrum deployment.

Pre-prod deployments are hugely useful when tuning a Spectrum deployment. For example, if tuning the match rules in a Spectrum job, it's best to tune in a pre-prod deployment. Then when the desired results are achieved, promote the new match rules to the production instance.

Additionally, pre-prod deployments are useful when troubleshooting issues with Tech Support, Engineering, or Professional Services.

Again, many clients do maintain a pre-prod sandbox deployment. And we've seen many who do not. So, we strongly encourage this as a best practice when preparing a solution with Spectrum.


------------------------------
Brian Casteel
VP, Engineering
Austin, Texas