Archive for the ‘ALM’ Category

[caption id="" align="alignleft" width="333"] One repository or many … the answer is neither[/caption]

One of the most commonly asked questions these days is “Should all our source code be in one repository?” This is a complex question and leads to a somewhat interesting set of answers.

Before we get to that lets try and understand the question a little more and find out why customers asking this? In IT we like to centralize and optimize. Gathering all the code in one place is seen as the next logical set of distributed data ripe for centralization and optimization. All in one place means

In the next few weeks Serena is going to be announcing important new versions of our ALM, Release and Deploy solutions.

Ever since Serena’s CEO, Greg Hughes, introduced the concept of “Move Fast Without Breaking Things” at our User Conference in Washington DC in February, we have seen an overwhelming acknowledgement from our customers and partners that this is the perfect encapsulation of what modern application development and deployment means to them.

For Highly Regulated Large Enterprises (we call

Serena Central - Your Serena community and marketplaceToday Serena Software launched our new community portal Serena Central which provides an enhanced user experience for customers and prospects looking to get the most out of their tools. The new site expands on our previous user communities focused around Build, Learn, and Connect.


What a terrific first meeting of the quarterly Dimensions CM Virtual User Group (VUG).VUG Group

We were joined by one of our early adopters of the innovative Dimensions CM 14 release, Carmelette Benson of Health Care Service Corporation. The VUG was treated to an exceptional upgrade story that engaged the free Upgrade Lab to advance their planning and readiness, and worked collaboratively with

CM_GraphicresizedOn June 10th I announced Serena Dimensions CM 14 – the best ever, and I am pleased to report that we have now secured a number of successful early adopters, many of whom are live and in production, and attracted a significant number of accounts that are now actively pursuing or planning their implementations and upgrades.

We have seen broad

“Drinking our own champagne” is how we approach technology here at Serena. If we have a our own tool that supports part of the application development lifecycle we use it for our own development efforts. In fact the Serena development teams deploy the beta versions of our solutions straight into their production environments because they want exploit the cool-new-stuff just as much as you do!

When I sat down today to start writing about automated deployment in modern enterprises I thought I’d follow the Serena mantra and “drink our own champagne” too. So I

System’s programmers on the mainframe have a pretty difficult time these days. More and more complexity, rampant growth of z/Linux, Websphere and RD&T boxes. Draconian constraints, compliance and governance mandates to be applied. All with fewer and fewer resources. It is a common problem.

Serena is here to help. Our ChangeMan SSM technology is designed to be the SysProg’s best friend and unswerving ally.

Sitting quietly in the background monitoring system datasets and members like the APF authorized libraries, the LINKLIST datasets, console commands and any

(This is the conclusion of a 7-part series. Read part 1, part 2, part 3,

Myth: Each deployment needs me

Helicopters have been described as “10,000 parts flying together in close formation. It is the mechanic’s job to keep that formation as tight as possible.”

Modern software applications comprise of millions of parts when you consider the huge chunks of code we bind into our applications from the database, security, web server, communications, encryption and authentication vendors. Add to that the seemingly infinite numbers of dependencies on external web services and internal CRM and financial systems.

There are 100 million lines of code in the Ford Taurus

But, just like the helicopter’s mechanic, the

Myth: Emergency fixes are different

“I don’t want to know why it happened: I just want you to fix it!” was what I was told early one morning by the Director of Sales. And she was right: getting the online store back online was the most important thing for the business. Blamestorming would come later.

There is a temptation at 3:00 am to just do whatever it takes to bring the system back on the air even if that means bypassing protocols and procedures designed to protect system integrity. Sales-and-Marketing and Audit-and-Compliance might not see eye-to-eye on this approach.

So why do emergency fixes have to be different? This myth is all about time. The time it takes to write the script.