cooper to logan - expressor software's semantic data integration blog

« May 2009 | Main | July 2009 »

June 30, 2009

expressor signs Sila as SI, tops 20 partners

News release today: expressor software has signed Sila Solutions Group as a systems integrator partner to target Fortune 500 companies, bringing the total of expressor's technology, SI and reseller partners to more than 20. Click here to read the full announcement.

- Steve Casey, marketing

Posted by expressor software at 12:00 PM | Comments (0)

June 25, 2009

Ab Initio under attack

Interesting blog from Philip Howard of Bloor comparing expressor's value proposition vs. Ab Initio to that of Netezza vs. Teradata. We like the comparison:

http://www.it-director.com/technology/data_mgmt/content.php?cid=11366

- Steve Casey, marketing

Posted by expressor software at 8:45 AM | Comments (0)

June 19, 2009

the perception of code and complexity

So there I was sitting with a trainee in a class the other day. He showed me what he had done in a competitor's product and indicated that there was 'no code.' What he had developed was a data flow with 30 or so steps. Each step did something fairly simple such as appending a new field to the output. I asked him to open a step up so we could take a look. Each step had a SQL statement, some fairly simple and some complex.

So let me digress for a second here. Is SQL not code? Sure a simple select statement might not be considered code. Often vendor specific SQL is used creating portability issues. When it can't be done with 'simple' SQL, and this is a real hoot, a stored procedure is created. My perception is that SQL is code.

Developers often know how to do things very efficiently using SQL. Developers know SQL so well that they don't even consider it code, it's SQL. And therein lays the problem. What about managers, data analysts, directors, C level executives and auditors? If you are a public company and therefore need to comply with the Sarbanes-Oxley Act, you have created a huge problem. You cannot have accountability without traceability. Traceability can only be accomplished with standards and best practices.

No matter which ETL / data integration tool you use you will be writing code to implement the necessary business and transformation logic. Some of this code will be generated for you automatically. Some of the code will have to be written by hand. So the question is not whether SQL is the right scripting language for DI. The question is how DI implementations can be more streamlined.

To assemble a customer's full name in SQL one might do this:

customer_full_name = first_name || " " || last_name

Sorry, not very apparent what is going on to a typical business user or perhaps a C level executive. How about this:

customer_full_name = concatenate(first_name, " ", last_name)

Most technical staff will argue that SQL, or any other language, is well known and so therefore the implementation turnaround will be much better. So ask the business user why is takes 3 months to add a few columns to a data warehouse table. Maybe it is because the business user has absolutely no insight into the process?

DI implementations can be more streamlined by actually providing real insight into the process. I believe that we at expressor have taken the right approach by providing a scripting language that is flexible, powerful, platform independent and most important, easy to read by all users.

BTW, the application mentioned above only needs one operator, no SQL, and zero lines of 'code' with expressor.

john russell, chief scientist, expressor

Posted by expressor software at 8:30 AM | Comments (0)

June 1, 2009

what total lifecycle management really means

What are the differences between your production and development systems? Your production system usually has more computing power. Probably has a naming convention that indicates it is production rather than development. And maybe tighter security. But real differences? None at all.

Think about it for a second. Production and development are implied concepts on every system on the planet. Management by permission, if even present, and naming conventions are all that are available in software lifecycle management, until now.
Imagine a system that on installation asked on what environment it is being installed. And if during installation you choose a production environment, the installation enforces a mutually exclusive nature and allows no other production environment to be executed from the software itself. Likewise if you indicate an install into development, system, integration, or a readiness environment, production applications are not allowed.

Let us take this a bit further and think about an application development system that simply will not allow changes in any environment except development because the system itself is lifecycle aware. That translates into a complete and traceable governance model with total accountability built into the system itself - not an afterthought or checklist that needs to be complete, but part of the development and execution management of the application.

What if this 'new' system took it a bit further and accommodated roles? In the old paradigm, project managers or architects have the authority to indicate when a project has completed development and is ready for migration to integration or production stages. Should they have permission to do so? Not likely, because this capability is outside the scope of their job functions. I have always advocated for a different role, a deployer, who may have no responsibility in development whatsoever but is completely responsible for migration to other environments.

Total lifecycle management dictates total governance and accountability in every single environment. With onshore and offshore models becoming more and more prevalent, with government regulations and theft of company data becoming common place, can you really afford to stick with what was once perceived as 'good enough?'

By the way, this subject is point #4 in our new 'top 10 reasons to choose expressor.' Click the link to read more.

- john russell, chief-scientist and co-founder

Posted by expressor software at 1:15 PM | Comments (0)