Ally Software Blog

Harmony Public Launch

Ally Software — Sat, 28 Aug 2010 21:51:38 GMT

After nearly a year in private Beta, I'm pleased to annouce the general availability of Harmony, by Ally Software.

Harmony is a new approach to managing complex projects and strategic initiatives that cross team, group, and company boundaries. Plus, it provides a central, bird's eye view for all company projects, with dashboard level status information.

Visit www.allysoftware.com and click "Download" to get access to Harmony. Once the download completes, you'll be asked to register you company - it's one page, and no credit card information required!

We hope you'll take the time to evaluate Harmony - we really believe it's a solution to making a lot of people's lives a little bit better. A few less meetings, not quite as much email, but better results.

And of course, we want to thank everyone that's been a part of the beta, and helped shape this product. We hope you'll stick with Harmony, and everyone who's will to give Harmony a tri

Features

Project Dashboard

The Project Dashboard is the heart and soul of Harmony, and the main tool for managers to significantly simplify their lives. The Dashboard elegantly surfaces company-wide project information with intelligent sorting based on project status. Managers can use this view to monitor their company's project execution, and Project Managers / Staff can use this view to make sure projects they depend on are running on schedule.

Resource Dashboard

Between the Harmony Beta and the public release, a whole new feature set was added called Resource Tracking. Harmony already helps you manage complex, long term schedules, but now you can add information about a project's resource requirements. For instance, a particular project might have a requirement for 3 software developers, 1 tester, and 1 project manager. Harmony let's you track this, and assign users manually or automatically. The resource dashboard is then a high level view of your company's utilization - who's assigned, who's on the bench, and who's over-committed.

Project Timeline

The project timeline is where you build the schedules and dependencies that drive the dashboards. Each track, or swim lane, on the project timeline is a seperate group, team, company, or individual with responsibilities toward completing the project. Within each track, the boxes represent phases, a push from a particular team to get work done, triangles represent milestones, and dashed lines are dependencies. For instance, Engineering might have a phase called "Develop Beta," and sales might have a phase that starts right when the "Develop Beta" phase ends called "Recruit Beta Users". At the end of a project, and final milestone might be the anchor that every other phase tracks backwards from.

Resource Timeline

The final piece of the puzzle is the Resource Timeline, a single view that show's you how individuals at your company, or in a specific group, are currently utilized or scheduled to be utilized. Think of the resource timeline as a pivot on the Project Timeline, where instead of showing phases, we surface the individuals assigned to those phases and summarize all their commitments in one screen.

Vote for us starting 10/9 for Enterprise 2.0 Launch Pad!

Ally Software — Fri, 09 Oct 2009 01:51:51 GMT

Ally Software is in the quarter finals for a contest to present during the Enterprise 2.0 Conference, in San Francisco starting Nov. 5th. We need your vote! See our video below, and vote for us at http://launchpad.e2conf.com/vote-now/

Meet Harmony, by Ally Software

Ally Software — Fri, 25 Sep 2009 03:02:07 GMT

I'd like to introduce you to Harmony, by Ally Software. Ally Software was started with a simple idea - help people have fewer meetings, get less email, but produce better results. There are a lot of Business Processes that are stuck in Web 1.0, and that means information isn't being share isn't as quickly or efficiently as it could.

Harmony is our first product, and it's going after a big problem - coordinating work on complex projects. Projects that span groups, teams, and even companies. Projects that involve many groups that may all have their own PM's. We're focusing on this because, funny thing, the more complicated the project, the more people have to fall back on emails and meetings to get work done, and the more likely those mediums will break down or become burdensome.

Simple projects, or small pieces of big projects, can use Microsoft Project or Excel for management, but big projects are different. There are too many moving parts, too many people involved, and too much at stake should the right information not get to the right people. There's a reason defense contractors call these meta-projects programs, and there's a reason program managers exist. Most companies have the same complex projects, but what they lack are dedicated resources managing the cross functional aspects of the project. They rely on meetings and emails, and things fall through the cracks.

Harmony is a meta-level solution for companies to plan projects that cross organizational lines. It's the first solution to easily allow dependencies between different phases in different groups. It has an interface that quickly shows the impact of schedule changes and communicates out status updates effortlessly.

There's more to come, including a chance to participate in the beta. But this is an intro, get excited about this space is changing.

Developer Diary #2 - Tokens and Claims

Ally Software — Thu, 25 Jun 2009 20:05:23 GMT

Development is iterative, we take that for granted. But iterations can be painful, excrutiating chop jobs where you rip the very heart and soul out of your product, only to replace it with something bigger, better, and stronger. Ally's authentication platorm went through a process like this, and while it was painful and took way longer than it should have or anyone would have liked it to, ultimately it was the best thing for the company.

Let me start by saying, there are hundreds of ways to handle authentication in web services. There are RESTful ways, implicit ways, explicit ways, certificates, usernames, explicit tokens, SOAP tokens, and any variation of combination there of. The first iteration of the Ally Auth platform used explicit username tokens, everytime you made a call, you passed in a token that had a username and password. Your username and password was authenticated and roles were assigned to you. A few problems exist with this setup: first, every service you called to has to have a connection to either a shared auth service or a direct connection to the users database. Definitely not preferable if you're trying for a true seperation of duties SOA architecture. Secondly, and perhaps more painfully, every service had to either keep a mapping of users to roles, or in addition to a simple authentication with each request, had to do a role lookup. With caching and client side "cookies" you could mitigate the performance impact, but the design with inelegant and maybe even a little painful.

After contemplating this, we decided it wasn't right. This isn't how you're supposed to do things. More to the point, what if we want to integrate with onsite authentication stores, at some point? There's no way to do that with a system like this, it's just too inflexible. So, breaking the problem into two parts, we looked at a) how to address repeate authetication in an elegant manner against multiple services, and b) how to manage roles / authorizations in a not-ugly way.

Tokens solve the first issue. We moved to an Secure Token Service (STS) model whereby on the first call to any Ally service, the caller is redirected to an authentication service that requests username / password, and if correct supplies a signed and dated token that can be used for direct calls to the webservice. Even better, the same STS can grant impersonation tokens to Ally services, but more on that later. The token was simple, it merely indicated to a calling service that some sort of authentication had occurred, nothing more.

Claims were then attached to the Token. Here now, the beauty of the Token / Claim system comes into play. Instead of explicitly defining roles such as "ProjectManager" the token contains information about the user, his user ID, email address, company, etc. With this knowledge, the individual service can now do their own authorization, or store their own ACLs.

Getting back to the impersonation, say one service needs to call a seperate service, perhaps to update the company information. Every service can be programmed as though a user is directly calling that service, and all authorization can be done against a user's token. So instead of having to program foreward facing and backoffice services seperatly, a front-end service wishing to make a call to a backend service requests an impersonated token for the current calling user, then makes the call to the backend. This brings up an additional point of elegance, as now if we want to create a website that offers direct access for a user to that backend service, all the authorization work is done correctly, and there aren't two authorization schemes at work (one for users directly calling, one for sevices calling).

If you want to learn more, check out the Geneva framework from Microsoft, it's what we're using (with WCF) and it is seriously cool.

Developer Diary #1: Screen Space Dilemma

Ally Software — Thu, 12 Feb 2009 19:49:15 GMT

The developer diary will be a place for our developers to talk about the pitfalls, gotcha’s, solutions, and technology they’re working on. Sometimes these posts will deal with Ally, sometimes they’ll be completely unrelated, but always (hopefully) insightful.

I wanted to comment today about how screen space has changed in the last few years. Specifically, we live in a horizontal world now, and that just wasn’t the case before. Back in the bad old days of CRTs, the 14 square inches of screen real estate didn’t much care if your UI was laid out horizontal or vertically. However, because people have become so used to vertical text flow in books (I suppose I should say especially people from western cultures), normal UIs were designed vertically oriented. For instance, menu bars always live at the top.

The change to wide format LCDs has made this interesting – I don’t know too many people who keep their start menu on the bottom anymore – the real estate is too valuable. So, as we began to develop one particular part of Harmony (this will be enigmatic until we actually talk about the product), we started with a vertically oriented layout. I felt the aesthetics were better, the flow more understandable, and the UI more disruptive. After early testing with customers, I was patently told off. A vertically oriented layout (for what we were trying to accomplish) was the wrong solution. Since our target customers tend to have big monitors, they were extremely annoyed to be wasting large chunks of screen real estate.

Once we start talking about the product, I’ll refer back to this post and add a little more insight and maybe some prototype screen shots.

Remember, Ally is gearing up for a beta in March, if you’re interested send an email to beta@allysoftware.com.

What would you say you…do here?

Ally Software — Thu, 12 Feb 2009 18:50:52 GMT

Hi, my name is Patrick White and I’d like to introduce you to Ally Software. Ally was started 6 months ago, and originally addressed a funny little problem – email overload. One of my pet peeves has always been email overload, especially having worked as a Product Manager. The question I posed was, how can I decrease my email, or increase my throughput? As anyone will tell you, it’s not an easy question to answer. There are solutions you can put in place for people to get answers to questions they might otherwise ask through email and there are tools that will help you quickly respond to an email, but in both cases I felt the overhead wasn’t worth the actual time savings.

As Ally began to mature, and we began developing prototypes, I started to understand the broader role email plays in organizations. I realized that what we were really attempting to develop was a solution to decrease explicit communication (I use the term explicit here very intentionally). Email is so powerful because of the way it breaks down traditional lines of communication and silos, so the problem we were trying to solve should never have been how to deal with email itself, but instead how to create more implicit communication across groups and silos.

Ally Software’s first product, Harmony, is launching in June and directly addresses one of the most complex aspects of cross group communication. I’ll share more as launch gets closer, but in the meantime, if you’d like to be a part of our Beta in March, feel free to email us at beta@allysoftware.com.