Getting Started With Workflow - Getting Your Feet Wet with Your First Production Project

In life, we remember most of our firsts. First kiss? Sarah in the second grade. First car? Mom and dad's 1987 Ford Taurus.

Today, after completing the mechanics of our last interoperating component to check the status of an incident in CA's Unicenter Service Desk, all of the major requirements set out by my internal customer two months ago were (finally) met.

I proudly announced to my project manager that we're ready to demo the end-to-end for our internal stakeholders. That meeting's been scheduled for next week. It's an important meeting.

If I could turn back time to our evaluation period, there are a few key insights I'd share with the me of then. These insights are the primary thrust of this, my first in what I hope, based on your feedback, to be a series of articles on this process.

First, let me mention here that Altiris is my full time gig. We utilize Altiris to manage our endpoints. I support NS and DS infrastructures, train and interact with project teams, and roll out solutions to help all areas of our business help our customers. In fact, I just wrapped up training our support personnel earlier in the week on Real Time System Manager, which will really provide us a whole new way of handling out of band unmanaged machines.

How did I get here?

It started innocently enough. I was lucky to attend the first Workflow sessions at Managefusion in 2007 when then Transparent Logic was partnering with then Altiris to add a whole new level of automation to our enterprises. I got it right away, and after getting word of some free training for Altiris customers being offered on what was then called LogicBase out in Virginia, I hopped on a plane, took a week's vacation, and learned about components.

I had done some initial internal product demos upon my return. We were looking at maybe buying the product in 2008, but then merger mania occurred. Not just for Altirentimantec, but also for my company. Our parent companies were getting a divorce. Out went my dreams of implementing Workflow anytime soon.

After integrating a few NS's, and working to standardize everything under a unified company approach, my team and I were starting to look at budget items for this new year, and I had, in my free time, setup a little demo Workflow server with some automatic machine deployments.

I demo'd it to my boss, who said hmmm... maybe we could use that in a totally different space - self service.

He got it too.

So the idea then was, why not use Workflow Solution to help automate a lot of the on-boarding and off-boarding processes for the enterprise?

I made up a few mock workflow menus in Form Designer, did a few demos, and The Great Journey began.

Things you need to do

First things first: Have the business process on paper and signed off by all necessary stakeholders. I was lucky. Most of the process documentation was complete and signed off on before we came to the table.

Do that before the product buy. Why? Because if you can't get that agreement among people, you shouldn't bother buying the product. Workflow is an amazing toolkit that can do amazing things, but only if it's told what to do. If you have systemic process problems in your organization, this won't be the cure-all. It will only become shelfware that reminds you and everyone else in your organization of just how unclear things are where you work. You don't need that.

You need details. You need to know who needs what when where and how.

Setting Expectations

Whatever you think it will take you to complete your first workflow, multiply that timeframe by 4. Don't make any hard and fast commitments. If you have a full time job that requires 100 percent of your time, and you're asked to do this also, recognize you will be spending nights and weekends working on this. You will find out that some Saturday afternoons in your cube or office can, believe it or not, be magical.

Don't kill yourself. Don't ignore the weeds in your NS or DS gardens, either. Nothing will make your newfound life doing what my co-workers call 'moving pictures around' more nerve-racking than an untended NS server taking production services down because you didn't weed the garden last week. Setting timeline expectations, as well as ensuring either additional adequate production support backfills or project support from Symantec or Symantec parters will go far in making your first workflow a successful one.

Where to Start

Go to training. The sessions are being scheduled more regularly now. Get an idea of what you're looking at before you make promises you may or, without training, more likely will not be able to keep.

I've found that choosing the easiest process flow as our first flow was an insanely great idea. Easy by some standards but maybe a little more difficult than a basic approval worklfow. To give you an idea, our first workflow has 3 integration components which talk to our third party help desk ticketing system, our Active Directory infrastructure for user authentication, portal account management, and approval mailing through Exchange, and lastly our internally built, custom SQL Application inventory database. I'll dig deeper into our project in later parts of the series.

Get to know the components as well as you can.

Flashcards may not be a bad idea. Component knowledge is critically important to solving problems within your organization. They're the literal tools you'll use to solve your business problems. Ever try to hammer a nail in with a stapler? It can be done, yes. But it will usually take an inordinate amount of time, require a whole lot of unnecessary code, and leave you, the Altiris guy or gal, frustrated.

The Design Meeting

Rule number one of Workflow design: Your initial signed off process? It will likely change as you develop the code. Wait a minute. Develop code? So you might be thinking what I'm asking about code development, and how it's involved.

Herein lies a piece of information you need to understand. Creating a workflow? It's coding. It's pretty coding, it's drag'n'drop coding, but it still follows the same foundational rules you may or may not have slept through learning in IT undergrad. Why do I bring this up?

Because thinking like a developer or being one will move you along the curve of workflow development faster. What does it take to think like a developer? Some ideas:

1. Document as much as you can given the time constraints you're provided.
2. Add hours for documenting to your initial project plan.
3. During the documenting hours ask yourself:
     • "What would I need to know to understand what I've done here six or nine months from now?"
     • "What integrated project components are vital to this little piece of my pretty project?"
     • "In planning for this component, did I make any unnecessary garbage that I can clean up now?"
4. Be consistent. If you're numbering, say, a login component result to the Fabrikam_HR_Universe, and you're using a result_component1, result_component2 format, stick with that format in all of your result components. All it takes is one ResultComponent3 to start down the slippery path.

The design meeting though, is not a time for code, or for you to discuss code with your customers. It's about process, and being a human sponge. Soak up every detail of your design meeting. I still have the photos taken of the whiteboard during our design meeting and use them as an invaluable resource to step back from the minutiae of a process to get clarity on how everything piles into the bigger picture.

If you can't follow the logic of how an idea your customer raises during a design meeting, make sure your resource assigned to the task can and does.

After the meeting

Either you or your project manager (ideally both) need to reassemble the process into a workable reference. In my experience, my PM was very aware of key process areas. Share those notes and that document with the team. Keep it as a living document throughout the life of the project.

Getting Started

There's some great documentation on workflowswat.com and on www.altiris.com/support/documentation on Workflow. Get familiar with how others have created workflows.

Set up the sample workflows in a lab and look at how error handling is considered in those projects. Look at how component relationships are built.

The first piece of this project I put together was our authentication token, which grabs the current user data, and displays it on a request form presented to the customer when they access the workflow. Looking back now, I've redacted that component 4 times in the life of building that workflow.

Did it work in my first iteration? Yes.

Does it work now? Yes.

What's different? The needs of the process downstream, which I hadn't and really couldn't analyze at that time, required I use a different component for gathering user data in general. Could I have left the initial solution in place? Theoretically, sure.

However, I'm following a few of the rules I mentioned above. Consistency is power. It's also less of a drag on your workflow performance. If you have 3 integration components, all keying values from the same, say, active directory source, how do you think your workflow will respond? Let me put it this way: How many keyboards do you have connected to your machine? You have one keyboard. Why? Why not have 2? You probably have two monitors connected, right?

Why leave the keyboard in the dark? Here's why: You only have two hands. It doesn't make sense to have a separate keyboard for tasks on the same box, right? The same sort of logic applies here.

Wait! You say. What if I'm 98% complete with my workflow, I've got a deadline looming, and all I need to do is add another integration component for the manager's email value, which we didn't realize we wanted until the last minute?

You're not going to make me go back and re-do all of the user query objects to use that new DLL are you?

Of course I AM.

Here are a few reasons why:

1. Lighter code as I mentioned above. (1 keyboard)
2. Upgrades and revisions to code
3. Checking your documentation - do I have everything I need to re-create this component? Where am I weak?

Stay Tuned...

In the next part of this series, I'll be covering some problem troubleshooting and the Red Screen of Death.