Blog

In general, there are six different types (archetypes) of line of business (LOB) applications prevalent in modern corporations today: Rich Client Applications – Applications of this type are usually developed as stand-alone applications with a graphical user interface that displays data using a range of controls. Rich client applications can be designed for disconnected and occasionally connected scenarios because the applications run on the client machine. Web Applications – Applications of this type typically support connected scenarios and can support different browsers running on a range of operating systems and platforms. Web applications have no client-side scripts or components. Web servers only serve HTML to the client. Rich Internet Applications (RIA) – Applications of this type can be developed to support multiple platforms and multiple browsers, displaying rich media or graphical content providing a higher fidelity of user experience than traditional web applications. Rich Internet applications run in a browser sandbox that restricts access to some devices on the client. Services Applications – The basic goal in this type of application is to achieve loose coupling between the client and the server. Services expose business functionality, and allow clients to access them from local or remote machine. Service operations are called using messages, based on XML schemas, passed over a transport channel. These applications may be part of a service-oriented architecture (SOA) or just a bunch of web services used for specific application solutions. Mobile Applications – Applications of this type can be developed as thin client or rich client applications. Rich client mobile applications can support disconnected or occasionally connected scenarios. Web or thin client applications can support connected scenarios only. The device resources may prove to be a constraint when designing mobile applications. Cloud-based Services/Applications – Applications in this space describe deployed services into either a private or public cloud infrastructure. Many organizations naturally have a combination of most or all of these (maybe not cloud services/applications yet!), some of which are packaged applications, while others are developed in-house. So, here’s the question: are the populations of the different types of applications random or are there patterns to the types of applications determined by some set of drivers? From what I’ve discovered, management concerns drive many of decisions to deploy applications of specific types, namely Web applications. Arguably, these types of applications enjoy low deployment effort and cost compared to other types of applications that require components to be installed on some client device. The services that comprise web applications can also be centrally monitored without having to track utilization, configuration, and failures on client computers for the most part. The downside of these applications is that they tend to have low fidelity of user experience compared to any other type of application. Now, if you’re an optimist, Rich Internet Applications (RIA) have the best of both worlds between providing a rich user experience and having a relatively thin client footprint, in some case relying on a user experience engine such as Microsoft Silverlight . On the other hand, the pessimists out there would claim that RIAs introduce client deployment and management overhead that present significant associated costs. The other types of applications have their own management overhead regarding deployment, configuration, and monitoring. In subsequent posts, I’ll address some of those issues. In the meantime, let me know what you think? Is your organization deploying a preponderance of web applications with a trend toward RIAs? Or, do you have some other type of profile? If so, why? Inquiring minds want to know. All the best, Erik

Successful adoption of Service Oriented Architecture has been a topic of discussion pretty much since the beginning of its introduction to enterprise businesses five or six years ago. As companies have worked to adopt this approach to building more reliable and agile applications at a lower price, they quickly found that it wasn’t as easy as it was to build the monolithic applications of old or even the n-tier and Internet applications that became standard archetypes in the late 1990s. While those types of applications certainly require solid application development, deployment, and management discipline, SOA introduces several new dimensions to the challenge of successfully adopting applications built on this architecture. Applications that rely on SOA have two inherent attributes that do not necessarily exist within applications based on other architectures. First, the architecture promotes the composition of ever-smaller atomic services into higher-order services (a ProcessOrder service, for example, has ValidateCustomer and CheckCredit services associated with it). This “feature” introduces the potential for hundreds or thousands of these compositions to exist in the enterprise (or, in some cases, outside the organization’s firewall; more on that in a subsequent post). Second, services based on SOA are autonomous and stateless by nature (or, at least, they should be!). As such, they can be created and exposed by anyone in the organization as a completely independent island of functionality without being tied to any one specific application. While both of these elements of SOA can certainly benefit enterprises who wish to accelerate the creation of custom, line-of-business applications through the promise of service reuse, the dark side is that services can proliferate out of control. Adopting SOA doesn’t inherently enforce reuse. Corporations may have multiple versions of a “CreditCheck” service created by different departments. Further, these services don’t necessarily have well-defined service levels defined for them that are backed up with enforceable service level agreements. While this may not be a significant problem initially, it can be a serious concern to organizations that want to adopt SOA as a strategic direction within IT. The nature of application development and maintenance changes since the development cycles, feature requirments, and service level requirements become decoupled. While there are many potential impediments to SOA adoption, which I will post more on later, the discipline of governance and the implementation of robust service management is central to long-term sustainability of applications that rely on the services within an SOA. Here’s why: Many organizations view service orientation as overly complex, without enough supporting tools to properly manage service artifacts. There is an inconsistent use of repositories and/or registries for defining service levels, availability requirements, and providing adequate discoverability (for a good description of repositories and registries, see Keith Pijanowski’s article on this. Policy enforcement at run-time in many cases is non-existent or is spotty at best. Good service orientation mandates a consistent approach to data access. This implies that data management, including master data management (MDM), consistent access to structured data (as stored in a DBMS), semi-structured data (as you might find in search service such as SharePoint), and unstructured data (as exists on a file share), must be taken into consideration. Security and privacy must also have a strong focus. Metrics definition and reporting is elusive. While specific services on individual servers can (and often are) monitored, having an all-up view of a related set of services that provide a business view of the health of the application is an altogether different beast to tackle. Production testing and troubleshooting gets harder to implement. As services proliferate, a failure at any point along the way will be harder to pinpoint and diagnose, particularly if the failed service is part of one or more composite services. Subsequent posts will delve into each of these as well as other adoption issues. For now, we’d like to get your feedback on the list above and the subject of service management. What resonates with your experience and what doesn’t? In particular, I’m curious about whether application performance issues represent an impediment to SOA. In my experience, this hasn’t bubbled up as a tier one issue, but I invite you to prove me wrong. All the best, Erik, Application Platform lead, War on Cost Team

Happy New Year and Welcome to the IT Business Value Blog. Like others within program management at Microsoft, our team of strategic program managers (PM), including Elliott Morris, Bruce Gary, Brett Williams, and I, work within the Windows Server & Tools division at Microsoft to help shape the future of the Microsoft platform. However, unlike our peer PMs who mostly focus on particular product feature design, our focus is different in that we focus more on identifying business value enablers and inhibitors across various customer segments to better understand what our customers need from the future versions of Windows, our management platform with System Center, and our Application Platform.

I will be moving Projectified to the following address: https://blogs.technet.com/projectified/ The same FeedBurner RSS feed  ( https://feeds.feedburner.com/Projectified ) should still work as I changed its settings to point to the technet blog. This site will stay up for a long time or until I can figure out how to bulk export the posts from here and import them into the TechNet blog.

Few things are more frustrating then using a system and being presented with a field you MUST fill in to continue at a time when you don’t know which value is appropriate for that field. Project Server is no exception. You can make any enterprise custom field in Project Server a required field. At the project level this means that a project cannot be saved until each of these fields contains a value. This is great if you know for sure that the project manager will always know which value to pick from the list at the time they first save their project. But if they don’t you have a couple of things that are going to happen and you need to be prepared for them and decide if they are your intended consequences. The project manager will NOT save their project until they find the answer (remember that the answer COULD be several days away.) Do you really want the PM to NOT save the project because they don’t have the answer to this one field? Where will they start their planning in the mean time? Where will their data go? The project manager will pick one of the values from the list just so they can save the project even if that value is not right. Remember that they may not remember to come back and fix it when they have the right information! The project manager will curse you (the administrator) and pray to their God that you be injured in some way very soon. Number 3 is going to happen for sure, count on it. What you have to decide is if you want number 1 or number 2 to be happening while your curseinjury takes place. The easy way to avoid all three is to either NOT make fields required unless you 100% sure that the project manager will know which value pertains to their project OR provide them a “Not Yet Known” value in the lookup table. I tend to prefer the “NOT YET KNOWN” option. It allows your views and reports to show which projects have complete field profiles and which projects are in need of more complete data. Just make sure that the people you have creating reports and views know to allow for this value in their filters. This means that if you want to show all projects where a field equals “X”  or “Y” that it should also contain projects where it equals “Not Yet Known” because those projects MIGHT be “X” or “Y”, we just don’t know yet. 🙂   Technorati Tags: Project Server , EPM

Reason number one is that in all but the most extraordinary situations it is modeling a situation that is just not possible. But first some background on what Max Units really is. Max Units defines the percentage of a resource’s full calendar working “period” that they can be assigned to work on tasks before Project sees them as being over-allocated. Example: A resource’s calendar says they come in at 8am and work until 5pm and take a 1 hour lunch. They do this Monday – Friday. That is an 8 hour work day40 hour work week. So if the Max Units is 100% then if the resource is assigned to work 9 hours in one day they will be seen as over-allocated. Same for if they are assigned to work on 2, 1 hour tasks during the same hour. This goes down to the minute level too so if two 1 hour tasks overlap by 1 minute then for that 1 minute they are over-allocated. This helps the PM create models of assignments and get an idea of how many hours each team member is being assigned to tasks and how that falls across time, other assignments, etc. So now you might be seeing what is wrong with 100% Max Units. It says that if I work an 8 hour day, I am available to work 8 hours on tasks. On it’s face this sounds logical but dive a little deeper and it becomes obvious that this is just not possible. Nobody ever arrived at work at 8am, took a 1 hour lunch, and then left promptly at 5pm AND got 8 hours of work done on tasks. EVER. OK wait, I take it back. It is possible that someone did this on your project:  IF your project schedule has tasks for things like: going to the bathroom, answering non-project related emails, going to a company meeting, being tapped on the shoulder by your cube-neighbor and being asked for “just a quick 5 mins. of help” (that turned into 30 mins), the list goes on and on. So if your project contains a task for every possible distraction from YOUR project and you expect your resources to track all of that then never mind. You can set your Max Units to 100%. (just count on a lot of churn on your team.) But for most of us it is not possible to work 8 full hours on PROJECT WORK in an 8 hour day. Doing so means that you were present for more than 8 hours so that all the other things had time in your day along side your real work. The best way to help our models (because that what project schedules really are: models of what we want our project work to look like) be more accurate is to lower Max Units to something more like 85%. That would be the highest I would ever go on any project I was managing. I have seen it set as low as 75% at some sites but generally I see 80-85%. What this means is that if you have a 1 day duration task and you assign a resource that has an 85% Max Units value, Project will calculate the Work for that task to be 6.8 hours. This means that you are modeling that on average this resource spends 1.2 hours of their 8  hour day doing something OTHER THAN working on your project. A Max Units value of 75% means that 2 hours is spent doing other things. Of course some will get more than 6.8 done in a day and some will get less done. It depends on the nature of their job, their relationship with other projects, other teams, etc. So the value you set will never be perfectly accurate but it WILL certainly be MORE accurate than 100% which is nearly always wrong. The point here is to make your model as accurate as you can.   ____________________________________________________________ I’m hoping to start a small series of Deployment Practices posts here covering things I have found to be useful ideas, practices or methods for deploying Project Server. Please email me if you have suggestions or questions. Technorati Tags: Project Server , Resource Management , EPM

OK it has been a while. I have been doing a bunch of the normal consulting thing these past few months. Helping customers better understand how to configure their Project Server environments around their business processes (and often helping them understand how their business processes might be changed to take better advantage of features.) I have also been doing some side-work projects. Working again on putting more meat on the bones for a framework for iterative designbuild loops for early rolloutproof of concept phases in Project Server deployments. The early stages of an addin for Project Server that would allow administrators to control which projects a security category allowed access to based on some defined set of project level criteria. 1 is something that has been kicking around for a long time and I hope to get moving on soon. 2 is much more recent and I think also more exciting (which means it will likely get done first.) It would allow you to have a category that would give permissions to projects based on the value in a project level custom field rather than just on relationships to the project. Email me your thoughts on either of these if you care to share them. I will be better about updating. 🙂 Technorati Tags: Project Server

I saw this post at Learning about Lean via Frank's Focused Performance blog and it speaks well about the issues we all face as consumers of data and information. But more importantly it made me think about WIP for the first time since I was doing process and project management work at Boeing in 1996-1997. I thought a lot about it then when I was dealing with manufacturing but not so much since then as I have been doing 'info work.' The thing it made me to tonight was to think about not just my inbox (as Joe Ely mentions directly) but also about the partly finished “things” I have laying around and the creative price of not having all of them done. It made me think about the partly finished specs for Project Server addin's that I had to put aside for other more pressing commitments and it made me think about the half incubated ideas for papers and blog posts that I scrawled down when I was on a plane or in a meeting and an idea hit me but I had no time for finishing it out. I think the real price is that as I go back over some notebooks and OneNote sections that hold these seeds I am struck by how complete I remember the thought being when I made the note and how incomplete I think they are NOW. I have lost something between then and now. I'm pretty sure I can get it back but how long am I going to have to think about each of these ideas to get back to where I was 2 months ago? So what I took from Joe's post (even though it was not what he wrote about exactly) was that I need to do a better job of documenting what I know will become long term on-hold WIP so that when I get the chance to get back to it I will not have to spend hours rethinking it to get back on track with it. You all have these on-hold projects sitting around in notebooks and in Word documents. How many of them are in a state where you could pick them up right now and start working on them without a lot of re-publishing and rethinking? Think about it.

Chris Boyd and Brian Smith do it again. Check here for two cool sample applications, one for showing how to create, read and update custom fields via the PSI and another used for reading custom field data and then publishing projects, again via the PSI. Check here for good info about OLAP cubes, Data Analysis (timeouts, plan guides and the tempdb)

The haters should note the date please. 🙂 This TechNet article covers the how to (Read it before you update): https://technet2.microsoft.com/Office/en-us/library/c3b86049-7cba-4b9c-8335-e37fb6e7518a1033.mspx?mfr=true Here is WSS SP1: https://www.microsoft.com/downloads/details.aspx?FamilyId=4191A531-A2E9-45E4-B71E-5B0B17108BD2&displaylang=en Here is Office Servers SP1 (which includes Project Server and Office SharePoint Server): https://www.microsoft.com/downloads/details.aspx?FamilyID=ad59175c-ad6a-4027-8c2f-db25322f791b&DisplayLang=en Here is Project 2007 SP1: https://www.microsoft.com/downloads/details.aspx?FamilyID=CEC3E1E2-D802-4A03-BC78-05C48472559B&displayLang=en Here is the Project Server MUI SP1: https://www.microsoft.com/downloads/details.aspx?FamilyId=D322BA67-B199-4503-8AFF-6813B320D708&displaylang=en Here is the Office Server MUI SP1: https://www.microsoft.com/downloads/details.aspx?FamilyId=3A6C26FD-0BEB-40D5-8CBA-15164FAAB150&displaylang=en And for Good Measure here is the Office 2007 SP1 download: https://www.microsoft.com/downloads/details.aspx?FamilyId=9EC51594-992C-4165-A997-25DA01F388F5&displaylang=en