Strategy needs translation to activity in order to preserve intent.  Otherwise strategy remains on paper only, and never becomes the actual direction in which we are heading.

I suppose I need to clarify that a little?  It’s a general idea I’ve been using in my day to day work for a while now, but I sometimes find it hard to explain in detail: I thought putting it in writing might help me work through some of the kinks.

I think the best way to reason through it is using a specific example, and since Vulnerability Management (VM) seem to be top of mind for me right now, I’ll use Security as the example.  Note that I’m not picking on Security as the only culprit here, I think we (as a company) do this all over the place, but Security is something I’m familiar with.

We had several major gaps in our security and compliance processes that we were trying to close with the VM project.  A perfect example is the identification and fixing of software patches within our environment.  The way this should work is:

  • someone is closely monitoring the releases of patches from the vendors
  • someone identifies which patches are relevant to the company and should be installed
  • someone identifies where the patches are needed (where the relevant software versions are present within the company)
  • someone creates a task to install the patch, routed to the correct group
  • someone performs the task, installs the patch

Or let’s think of another example: setting a security policy:

  • someone writes the policy that says “all databases containing credit card info must be encrypted”
  • someone interprets the policy for each of the databases in the company
  • someone documents the approved products, installation and configuration options to set correctly in order to meet the policy requirements
  • someone installs and configures the products to meet the policy

The problem?  All those “someones”.  Organizationally, what we have traditionally had at the enterprise hasn’t done a very good job of assigning the right people to those roles, mostly by putting too much of a wedge between the policy ‘definers’ and the policy ‘implementers’.  This got a bit worse as part of our outsourcing, but it was here all along.  We ended up with the following types of situation:

  • – someone identifies the software patches that should be installed in the company
  • – that info is handed over the wall to the operations teams
  • – ops teams don’t know where the patch is required, or don’t have enough operationally-specific information to install correctly/completely
  • – any questions back over the wall get the response: “We don’t do that, that’s operations, we just define the policy, you have to figure it out”
  • – the patch never gets installed


  • The statement “databases with credit card information should be encrypted” is made as a policy
  • The policy is handed over the wall to the ops teams, and they are told “go encrypt everything that has CC data”
  • The ops teams ask “where do we have CC data?  And how do we configure the 150 options that this encryption software has, to make sure we meet your expectations.  And how do we support this over time?  Who will be monitoring the logs, and who do they notify when something happens?  And what are the ‘something happens’ that you need to know about, and which are noise?”
  • Strategy teams says “that’s an ops issue.”
  • Ops team installs and configures software incorrectly, incompletely or ignores it in the absence of complete knowledge on how to implement and support it.  It’s not supported over time, and no one looks at the logs to see and respond to errors.

We need to improve the way the strategy groups respond to requests for clarification and understanding from the operations groups.  The best way to do that is make sure the conversation goes this way:

“Here are the standards and the policies and the requirements”

“OK.  How do I implement all that in this environment?”

“Hmm.  I don’t know.  But I know the strategy, you know the environment: let’s figure it out together.”

How do we do that?  Good question.  The recent work we’ve been doing to develop Minimum Baseline Standards is a great start, but it’s not enough to get five of these a year from a consultant, where they remain pretty much frozen in stone until the next year.  We need meetings between the strategy and the operations representatives to be a natural, regular part of business, and we need people whose main responsibility is to translate from one to the other, breaking down the high-level strategy to the detailed implementation, with full knowledge about both.  Otherwise the strategy remains on paper: ignored, implemented incorrectly, or implemented to barely satisfy the letter of the law, rather than the spirit inherent in the strategy.

How did we attempt this in VM?  By making sure that it wasn’t enough for the security strategy groups to identify patches that needed to be addressed in theory, but requiring they link those patches to the vulnerabilities identified, within our company, by our scanning systems.  Then translating the strategic view into an operational activity list: “here’s what we have to do, within our company, on these specific servers, in order to meet our requirements for our security strategy.  And here’s when you can do it, and here’s the group that is responsible for the task.”  It’s more work, sure: there’s the additional steps to map the identified issues with the enterprise-present issues, and map the issues to the activity required to fix them, and map the activities to the respective responsible and accountable groups.  But it’s necessary, and I’m not sure there’s a better or more efficient way to do it.

The same applies to all of our strategies.  We do a sub-optimal job of translating strategy to operational process to solve the “Monday morning 8:00am” problem, which can be expressed as follows: when a system administrator sits down as his/her desk at 8:00am next Monday morning, they have a thousand things they can do.  How do they know what they should do, and do first?  When they make a selection and start work, are they choosing the operational tasks that are (ultimately) prioritized, sorted and filtered by the company strategy?  Can you show that link from the company strategy to the first item done at 8:00am?  If not, then your strategy only exists on paper.

We have three different types of applications or software that are hosted on Citrix servers: pretty typical stuff.

  1. Fat client runs on Citrix, connects to a back-end hosted somewhere else
  2. Thin client (browser) runs on Citrix, connects to back-end hosted somewhere else
  3. Standalone client runs on Citrix directly, no back end.  Office applications (e.g., Word, Access) as well as full-blown virtual desktops fall into this category.

Option (2) always sounds like a strange one (wouldn’t any Citrix client also have a browser installed?), until you realize that we use those for remote connections.  We don’t allow direct access to internal applications from the outside world, but you can either VPN in or connect to the external network-facing Citrix boxes, and then run the apps from there.

We run Troux’s Enterprise Repository to model our Enterprise Architecture world, including the relevant parts of our application portfolio, and I’m trying to find the most appropriate way to model the Citrix relationships.  You see, in Troux’s world an application runs on software modules, which are instantiations of specific versions of software products on infrastructure components.  So as an example, an application (which is a business construct, referenced as a whole, different from the component pieces of software like MS SQL) called “HR Payroll Processing” runs on MS SQL 2005 on Server1.  In that case, the Application is “HR Payroll Processing”, the software module is “MS SQL 2005 on Server1”, which is an object that links the app to the server, and the infrastructure component is Server1.

We have never traditionally used any software modules for the clients.  In fact, we’ve never represented the clients (fat or thin) in the EA repository: never really needed to.  I’m trying to figure out whether it makes sense for us to model the clients that are installed on Citrix servers using software modules, or whether it actually makes more sense to use a different object type. Has anyone out there dealt with this?  Not necessarily on Troux, I’d be interested in hearing about experiences on any EA modeling tools.  My idea is that we would create, for the cases above:

  1. Software modules called “HR Payroll Processing Client – CitrixServer1”.  These would link to the application and the server objects.
  2. Software modules called “Browser Client – CitrixServer1”.  These would link to the application and the server objects.
  3. Software modules called “<Software name> – CitrixServer1” (e.g., “Outlook 2007 – CitrixServer110”).  These would link only to the server objects.

One of the complexities of this model is that we need to produce reports that show the owners for everything installed on the Citrix servers for DR and general operational purposes.  But now this means I have to assign owners to the Citrix installations of standalone software like Office, and the report will have to show the union of owners of the first two types (which is a secondary link to the application owner relationships) and the standalone software.

In the alternate approach, I create Application objects for each of the Citrix installations of standalone software, maybe make them children applications of a parent “Citrix implementation” app. This seems duplicative to me (an app called “Citrix Outlook 2007” that runs on a software module called “Outlook 2007 – CitrixServer1” that runs on “CitrixServer1”), in addition to going against our standard application definition which states that software <> application.  There are pros and cons to each approach, but we’re early enough in our EA gathering that we don’t know how this information will be updated and used in the future, so it’s hard to understand where the additional work will be least annoying: in the work needed to create additional application objects, or in the need to create output reports.  Either way, someone’s going to be doing more work than strictly necessary in order to make the output look consistent, and I know that if I have to create additional application objects that person will be me.  I’ll do it if I have to, but I want to make sure I’m doing the right thing.

Probably just open musing at this point: I know that if someone asked me this question my answer would be “it depends”.   Anyone else been working on EA modeling?  Anyone modeled their Citrix apps?

I’ve been burned by this one so many times it’s not funny.  Although if you like seeing me get frustrated, then I guess it is funny.

Here’s the issue: you have a SQL SELECT statement that you’re using in a Cognos Report Studio report, and you’ve verified that it is syntactically correct. It runs fine in Studio Express, for example.  But then you try to add a filter (also one that is syntactically correct) in Report Studio, and you get an error.  The SQL SELECT statement is correct, the filter is correct, but enable the filter and if fails.  What…?

Short answer: Don’t put “ORDER BY” sort statements in the SQL SELECT command. Your order statements should only occur in Report Studio.

Long answer: 

The reason this errors out is that when you put in a filter in the report (not in the original SQL SELECT), Report Studio adds that filter to the end of the SELECT statement it constructs.  So if the SQL is:  

SELECT ApplicationName from R_Applications

And you add a filter like “[ApplicationName]=’something’”, then Cognos bundles them together and sends this request to the SQL server:

SELECT ApplicationName from R_Applications 
WHERE [ApplicationName]=’something’

If the statement in the original SQL is

SELECT ApplicationName from R_Applications
ORDER BY ApplicationName

Then when Cognos sends the statement with the filter enabled it sends:

SELECT ApplicationName from R_Applications
ORDER BY ApplicationName
WHERE [ApplicationName]=’something’

Which is a syntax error: WHERE cannot come after ORDER BY.

Ta da!

Caveat: running v8 of Report Studio, I hear rumors that this behavior changes slightly in later .x revisions.

When you create burst reports or run any Report Studio report so that it sends the results out as an email, you have a few options on the format in which the file goes out. Some of them don’t work so well in our environment because of restrictions on file types that we have in our email systems, so .htm or .html files will never make it past our filters: that one is obvious. What other types can you send reports out as?

  • CSV: success!
  • XML: success!
  • PDF: success!
  • Excel: FAIL!

That last one is a little confusing, to say the least. I would expect XML to fail before XLS. There’s a reason it does fail, though: no matter how you attempt to send an Excel attached file, Cognos actually sends out an .mht file instead, albeit with a MIME type of application/vnd.ms-excel. In my mind this is astonishingly backwards, especially considering there is no indication of what it’s going to do and why.

In any case, here’s how to fix it: you must add a server parameter to send the mht file using an .xls extension. This means you’re still sending an .mht file, but it at least looks like, and behaves like, an Excel file. To do this you must add a server parameter.


  1. Click the Tools menu in the Cognos portal and select “Server Administration”
  2. Select “Set Properties” for ReportService
  3. Select the “Settings” tab
  4. In “Advanced Settings” (usually the first option), click the ‘Edit…’ link
  5. Select “Override”
  6. In the first empty set of boxes, type in the parameter name RSVP.FILE.EXTENSION.XLS and set the value to TRUE

Repeat the above steps to Set Properties for BatchReportService, and when you send the reports send them as Excel 2002 (NOT as Excel 2000 or Excel single sheet).

Not very smart, misleading, and the cause of the error you get when you try to open an “Excel” file that came from Cognos, where it states that the file is not in the format that the extension indicates. An error that you get every. time. you. open. the. file.