|
|
-
Social Websites have received a lot of attention in the past years, generally mixed with technologies such as AJAX. These developments have been referred to as "Web 2.0" because of the greater interactivity of web pages and the movement away from pure e-commerce pages which were the in-thing to do during the dot-com era before the bubble burst.
SharePoint 2010 comes with a set of new features enhancing its Social Networking appeal. Sites such as Facebook have received much attention one wonders what the value of these features can be beyond that. Furthermore wikis, blogs and other features impact the communication culture and break open structural silos. Such changes can create great synergies but also open every conflict inside of the organization. Is it worth the invest? Taking a broader view of the situation, the question is can I achieve more than just improving my communication with such features?
A central thesis of the book "The Wisdom of Crowds" from James Surowiecki is that a collection of diverse and independently acting individuals can achieve better decisions and make better predictions than experts given the right conditions. It draws on examples and experiments from the field of experimental economics. He also argues that market judgment can be much better than that of experts or a panel of experts.
While the final word on this isn’t spoken, there are numerous examples in recent time of how people come together to create something new, demonstrating bottom-up coordination or prediction via prediction markets. The oldest prediction market being the stock exchange, which incorporates information about companies and predicting its future revenue expressed by its price. Of course this example also conjures up the negative side of markets: stock market bubbles. Such examples demonstrate the potential lying dormant in organizations and technology such as SharePoint has lowered the bar of what is required to introduce such structures if it can be harnessed.
The “if” is the big point here: at this time we don’t know all factors which contribute to success or failure of markets or what leads to bottom-up coordination. Each organization has its own, unique communication style and habits as well as history – the starting point of every initiative which needs to be taken into account. Nonetheless the benefit already gained now coupled with the benefits one stands to gain in the future make a strong case for investing.
|
-
After clarifying where SharePoint Governance belongs in the big picture, it's time to take a look at new up and coming features of SharePoint 2010 that will make keeping control much easier. This will be one of several posts on this subject and each time I'll take a look at a different area. For the first post I'll take a look at the replacement for the Shared Service Provider: Service Applications and what that means for Governance.
In SharePoint 2010 the Shared Service Provider was replaced by a more flexible concept, the Service Applications. Service Applications are now managed via central administration and can be pick and chosen as needed. More importantly, Web Apps can chose which services they utilize on a individual basis or use one of multiple instances of the same Service Application.For the Governance of SharePoint this means a far more fine-grained control of what is utilize where. Either a Service Application instance is shared by multiple Web Apps or each one has it's own. By making SAs a Virtual Directory it is possible to isolate each one with an own AppPool. The SA communication is facilitated by HTTPS - a Webservice - so that is another surface that will require security consideration.
Custom Service Applications can be easily developed now - unlike in the SharePoint 2007 variant. Next to the Webservice surface, SharePoint 2010 comes with a Object Model which allows the custom Service Application to act like a out-of-the-box Service Application. This can be especially practical if one wants to have a scale-out strategy or one needs a central place to process long-running operations. It could also offer a central place to integrate custom governance policies which could be utilized by custom extensions and aplications. The one thing to consider here: how and when to develop such Services must be defined and monitored in detail.
One thing I haven't mentioned so far is the new feature multi-tenancy and it's implications for Service Applications: they can be configured to either share or partion data between tenants. Here is where the flexibility of the new Shared Application architecture really pays off: one can use one or several of them for different tenants as needed.
That was a short intro to Service Applications and it's implication for Governance. To sum it up: Governance becomes far easier through the new Service Application model. No longer are mutliple Services tied to each other. Also Services can be configured to share or partition data between tenants, if necessary allowing for a fine-grained control of everything - as needed. Finally, one can extend the System with custom Service Application but must take care to define how and when. All in all: much needed improvements to increase flexibility and control.
|
-
Governance is quite an abstract concept - but we all have a good idea what it's about. We experience it every time we talk with a government agency or pay our taxes. Laws are certainly the most strict form of Governance and encode our ethical beliefs. Aside from them there are a bunch of regulations, guide-lines and conventions which dictate how we interact in the public space.
Coportate Governance is in essence the same thing on corporate level. To recite Wikipedia:
"Corporate governance is the set of processes, customs, policies, laws, and institutions affecting the way a corporation is directed, administered or controlled. Corporate governance also includes the relationships among the many stakeholders involved and the goals for which the corporation is governed."
Important next to the fact that it involves processes, customs and policies to control the corporation, is that it is about the goals of the corporation. So corporate governance brings in line business goals and the behaviour of the people governed by it: the people working in the corporation.
IT Governance is a sub-category of Coporate Governance and focuses on IT Systems. In the field of IT Governance one can find a list of supporting references which can help with organizing and creating an IT Governance. Some are:
- Control Objectives for Information and related Technology (COBIT)
One of the leading IT governance and control framework and is published by ITGI (IT Governance Institute)
- IT Infrastructure Library (ITIL)
Focuses on the delivery of IT Service Management
- ISO/IEC 38500:2008 Corporate Governance of Information Technology
A standard for corporate governance from 2008
COBIT defines five focus areas:
- Strategic alignment
This is what I've mentioned already about governance in general: keeping people aligned with business goals.
- Value delivery
This area should ensure that the promised benefits are delivered and that this is done in a cost-optimal fashion.
- Resource management
This area controls and takes care of resources such as applications, infrastructure and of course the important one: people.
- Risk management
- Performance measurement
This area assures that not only is value delivered but that it is monitored and measured. Examples are project completion, resource usage or balanced scorecards.
While keeping control of an IT system is important (as anyone who has worked in a chaotic IT department can testify), the question is which benefits one haves from all the effort which the introduction of processes, guide-lines, etc. entail. IT Governance promises following benefits:
- Assurance that the IT is aligned with the business.
- Enabling maximum benefits from the IT
- Resources used in a responsible fashion
- Management of risks
- Drive down the costs for managing the IT systems
- Allows to compare and outsource services if needed
Again drilling down into details, SharePoint Governance is a Sub-Category of IT Governance. As with IT Governance, SharePoint Governance seeks to achieve business alignment, assure value delivery, resource & risk management as well as performance management.
Generally, companies don't think of SharePoint Governance in a concerted, wholistic manner. Normally the subject pops up when the system starts getting out of control. First when they stumble upon such things as conflicting webparts, unused content which clog the system or inability to react to business needs does the realization set in, that one has to act in a structured fashion.
Such a framework must stand with one foot in the governance arena and with the other must understand how SharePoint works to achieve these goals.
|
-
This is probably no secret to most, but developing is a craft. What are typical signs for a craft? Let me list the obvious:
- Not one piece of software is like the other
If you ask two developers to write the same software, the solution will be different. Even given the same software tools, there will still be differences between the results. Even more, if a developer wrote the same software twice, the results would probably be different. Every developer knows the phonomena of "If I would have to write it now, I would do it differently".
- Doing it for the fun
Most developers are developers because they enjoy what they do. They are in the are for the personal enjoyment. One of the reasons why open source works is because it offers people the ability to experiment and work on things they normally wouldn't be able to.
- Developers take pride it what they do
Closely linked to the previous point is this one. Everyone working in the field of development knows that developers take a lot of pride in what they create and have an aversion to creating what they preceive as "bad code". If project constraints (time, bad code structure, etc.) force one to do it that way, you'll always get an earful.
- Communication about new "techniques"
If one takes a look at advanced development books, you'll find that they have many basic solutions which can then be changed as the situation dictates. These templates - known as patterns - are communicated in forms much like surgeons do.
Surely there are many more indicators and examples, but I think this should illustrate my point.
So, if it is a craft, what does this mean?
As a developer, something to be careful of, are the inner workings stemming from development being a craft. Easily one starts developing things that are more "fun" then the ones that are necessary. This issue appears again and again in my blog posts, so I won't go into details here, but the principle counts: to any software construct, there must be a requirement calling for it.
Because development is a craft, this also means that experienced developers are by definition better. While this seems obvious, the difference is much more pronounced then on an assembly line for example. On an assembly line the performance of the individual has far less impact on the overall result then in a workshop-like setup which explains why experienced developers can command so much more income over inexperienced ones which sometimes struggle even to find a job.
This has lead to the rise of the title "Architect" as a differentiator between more junior and more senior developer and the job is to assure that the quality the junior colleagues deliver is acceptable. While many developers appropriate the title "Architect", a simple measure to assure a certain level of compareability would be to require a certain amount of years of work experience.
There are many forces out there trying to industrialize the process of software development. A very prominent example for this can be found in the Architectural Journal, No. 9 from Microsoft with the strategy of Domain Specific Languages and Software Factories which aims to adress exactly this issue.
The goal here is obviously to gain control of the production process by eliminating the dependency on individual performers and rely more on the process itself. At the same time, the designs should be standardized and consolidated creating exchangeable parts.
Principally every Library or API represents a standardization between products and every cross-plattform technology such as Webservices are like Industry Norms.
That these goals are not totally elusive shows the maturity which software has achieved so far. While there remains much to be done, issues like bluescreens or pointer-errors have vanished and software has become more reliable because of this. There is no doubt in my mind that this trend will continue, moving the skills necessary to implement software solutions for companies from Technology to Business. Things like memory model or calculation speed optimization with bit-shifting has moved into the area of unecessary or arcane. Of course the basics will continue to be relevant in some specific areas, but in the end, they will be a specialisation and a more industrialised process will be the norm.
|
-
While I like sharing some thoughts in detail, I often have things I feel I would like to share in short and quick fashion.
For that I've setup a Twitter feed. It can be found under http://twitter.com/AvanadeJustCode
|
-
I'm sure that some day I'll write a book called something like "How to develop software - NOT for beginners". Of course I'll have to be careful that it doesn't tip over to a whiny "what is wrong with software" thing, but there seems to be a universal set of errors I've seen developers make and I wonder why this hasn't vanished in the professional arena. I think part of the problem lies in the way software is initially taught and learned.
In the beginning most of the focus is on mastering development as such and the people writing such books generally use examples which have little to do with reality. And of course there are a slew of books teaching one how easy it is to develop with the newest tool. In my view that leads to developers so focused on developing a specific feature that they forget the other things around it. The third reason is a psychological phenomena known from the automobil industry: the more security built into a car, the riskier the driver. The same counts for development: because with modern languages such as C# one doesn't have to take care of every little byte, people tend to develop shoddy.
For that reason, I would like to list a few mistakes I've run into over the years - made by myself and others.
1. It's all about diagnostics
Diagnostic is the most important piece of the software - at least for the developer. That is the piece of code in your software that is of value to the developer. I do not understand why so many developers spend so little time on structured error handling and diagnostics. I'll put it in concrete terms: if you spend less then 10% of your development time on that subject, you are doing something wrong. Of course it depends on what kind of solution you are developing, but you should always be able to turn on/off your tracing, should always be able to log away something and you should always be logging any exception popping up. And of course: you should always be able to report to a user a concrete error message. I spend a lot of the initial time in development with setting up those things. If you are developing solutions for SharePoint for example, a infrastructure already exists in which case you don't need to invest quite as much time and can concentrate on wrapping it in such a form that you can use it in your solution.
It seems so obvious, but I seen far too many applications where developers didn't take care of it initially and weren't able to diagnose issues at the client because they had no way to find out what exactly was the problem. Especially nowadays when systems report fairly precisely (ok, I said fairly - it could still be better) what the problem is, one should think it is childs play to set it up in a fashion that such things can be diagnosed.
2. It's about defensive programming
Defensive programming isn't something terribly new. The archtypical "Assert" has been hanging around for decades now (literally). Another word in this direction is programming by contract. An article in the MSDN Magazin called "Code Contracts" appeared just recently, covering how the .NET Team is planning to integrate just that in the upcoming release of C#.
Because OO Programming tends to split up the code in many small pieces over several classes to achieve a functionality, the amount of code used in a method to check and verify entry parameters, return parameters, etc. can amount to more then the code which actually performs the operation. NullReferenceExceptions should not be happening! If they are, it is an indicator, that you have been sloppy. Ok - it still happens to me every now and then too, I'll admit it. But I'll also admit that I had been sloppy then.
Also another point: just writing Asserts doesn't cut it. I personally don't use Asserts any more: either the preconditions are met or they aren't and my code better report it if they aren't. That means that there should be enough "if not then throw exception" in your code. Of course that does have a performance impact but then most of the software I develop is not time critical (real-time, etc.).
3. It's about KISS
Although agile development has entered mainstream a few years back, most developers seem to see it as an excuse not to write documentation and just start hacking away at a piece of software. "Keeping things lean". I've written a post on my thoughts to agile development (here), so I wont go on in detail, but there are a few things to keep an eye on. Firstly, one needs to understand what exactly is the goal of the software. A lot of developers I've met, tend to pick up a few things, started to develop away at it and then show up with more questions. Getting a clear understanding in advance is important and I can't stress it enough.
The next thing I've seen is that a lot of developers over-engineer their software. They'll build all sorts of fancy "you can then exchange this component easily" elements into the software. A few interfaces here, a little bit of inversion of control there, etc. In my experience that kind of stuff is a waste of time unless esplicitly called for. I've seen people writing all sorts of Generic code (with T and without) which does the job just as well as the simply coded piece but of course with double the effort.
To put my critic into perspective: when called for, such generic code makes sense. If you know for sure that the code will change over time because you've built that kind of software before or you know exactly that the customer needs time to understand certain aspects of the software, then do it. But unless you have that concrete requirement, it is generally a waste of time. In my experience unless you are sure of what exactly needs to be generic, generally when the time comes, your generic code won't fit the bill either and you have to rewrite it anyway.
In that case an important agile tennant actually should also count: keep it simple. The easiest, most straight forward way is mostly the best solution.
Finally
So, I guess that sums up typical mistakes I see developers making again and again. Not using diagnostic extensively enough, not programming enough safe-guards into their software enough and over-engineering their solutions.
By and large I think the problem stems from the fact that many developers are in the job for the fun of it which leads to a divergence between customer wish and developer. The key here is to know when this is the case. Professional software is a service to a customer. The wish of the customer is paramount. A customer generally wishes a reliably delivered, easily useable software he can use for his daily work. Because of that extensive diagnostic and safe-guards are important for the reliability while not over-engineering is important to keep the expenses for the system for the customer low. The rest should be secondary.
|
-
I've just spent some time trying to figure out why I couldn't use a regular domain user as an application pool account in SharePoint.
To my scenario: I created a SharePoint Webapp using the standard Network account. As you all know, this is not recommonded. It came home to roost alright when I decided I wanted to configure the search machine. The system started balking and telling me I couldn't see any results. So after a while I decide to change to a regular account after reading that the Network account can cause problems with the search. That is when the real pain started. Suddenly the system was telling me that he couldn't access the configuration database.
I was surprised, played around with the settings on the database until I realized, that the problems must be happening earlier. Sure enough, I was getting the message "Can not access configuration database registry key".
After taking a look with regmon it turns out that for some reason the user couldn't read HKLM\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\Secure\ConfigDB. I've seen some people having similar problems and just granting either direct read or putting the user into the Admin group. Just as a hint: don't. At least not on a production machine.
If you've changed the App Pool correctly via "Central Admin -> Security Configuration -> Service accounts" (whoever came up with that place to configure webapps should strung up by the thumbs), then the user has been added to the Local Group "WSS_WPG" which is described as "Members of this group have read access to system ressources used by Windows SharePoint Services". This group also accidentaly has access to the very tree in the registry. But: now comes a little treat: the user still couldn't read the key according to regmon. After logging on with that user using regedit to assure myself that the user could read it, I was puzzled. On the off chance, I then removed the UAC on the server which asked me to reboot and - voilá, it worked!
If it was the reboot because somehow it was caching the registry access (I don't think so) or removing the UAC on the regular domain account I can't say - I didn't bother verifying it conclusively. But: if you need to solve such a problem, there you have my solution.
|
-
When starting into the field of IT, one often asks oneself what skills one should have, to be a good IT developer. With Avanade, one not only has to be a good IT Developer and understand IT, one has to be good at communicating such things. The foundation is IT of course. So, the question is: what does it take to be a good IT person?
IT Development consists of following areas:
- Software engineering
General software engineering skills. Typical examples are object-oriented programming or an understanding of operating system concepts. This knowledge can be gained by studying computer sciences or just working in the field long enough and gaining the knowledge from books, etc.
- Platform knowledge
A good understanding what the platform offers on which one develops. I have seen cases where good software developers ended up developing unnecessary, complicated and error-prone solutions because they were missing know-how of the API and/or language they were working with. In one case I saw how someone implemented a complete XML serialization because he was unaware that .NET already offered such out of the box. Especially beginners tend to underestimate this factor. If you hear something like "I can develop in any language and on any operating system", the person is probably a candidate for underestimating.
- Domain Knowledge
Having a good working knowledge of the domain one is working in, is an important component which tends to be underestimated by many developers. Yes, the first two factors are important, but domain knowledge is the basis for excellence. Understanding what others are trying to achieve with the software one develops helps to know which short-cuts and assumptions one can make without running into problems later and one can avoid typical pit-falls. E.g. when creating a website one should think twice which kind of content one uses. It might be nice to have current news on the page but it also means that one must think of keeping it up-to-date.
All threee components are important to be a good IT Developer. Each point builds on the previous one. 1) is so basic that one often forgets how important it is. On the other hand, beginners tend to believe that with 1) they are ready to conquer the world. 2) is often underestimated not only by beginners but also by management. This is because management tends to either focus on point 3) and/or because they can't differentiate between 1) and 2). Lastly, 3) tends to be underestimated by developers or overestimated by management. Important is the synthesis of all three components to be a good IT person. In my time with Avanade it has been my pleasure to work with a lot of colleagues who have this synthesis. Of course that is because Avanade expects people to come to them with software engineering know-how and works with the person to assure that he has the corresponding platform knowledge. (E.g. we must do microsoft certifications proving this knowledge). Domain knowledge is very individual of course and is gained as they work on projects with customers.
|
-
One story that is pretty hard to get out of the heads of developers is that things can't be estimated and therefore the whole process is useless.
In fact, estimation is one of the most important skills a developer must have is the ability to estimate acurately. And according to current research, it is possible to estimate within 10% of the real number. A good project manager is able to bring a project home, with a 10% variance. Unfortunately, many developers are not able to distance themselves from their daily work so much as to see how their work is also subject to statistic.
Furthermore, developers are craftsmen and don't like when their creativty is set boundaries. By saying "Development can't be estimated", they are in essence saying "Let me do what I want how long I need and see what comes out". Of course stakeholders can't accept such an approach. They want a regular and predictable delivery.
For one thing, its about 'Estimation' - it isn't expected that it is 'exactly' right. Of course it shouldn't be totally off and the earlier in the development process it is, the more variance is expected.
For another, there are enough statistics to go by to help with a basic estimation. If you follow the prescriptions from books like "Software Estimation: Demystifying the Black Art", you can achieve an astounding level of accuracy.
Of course it is also important that you get project-specific data as soon as possible. Therefore measuring how the work went and finding out why the estimate was off or accurate is an important part of project work. "Only who measures can manage".
And lastly, it is important to use the Avanade Estimation Model which consolidates the experience of many projects into a great tool.
Of course if you face a situation in which you must develop a piece of innovative software with unclear requirements and unknown technology, the variables with impact on the final number grow quickly and one might rethink how to work together with stakeholders. In such situations a iterative process with small steps is adviseable with a clear focus on delivering value quickly. Such issues should be communicated transparently though, because otherwise the project would start under a bad star, giving the team little chance to catch up with expectations. But even then, it is important to estmate and check the estimation on a continuous basis to gain the experience for delivering in a predictable manner.
|
-
Having been on several (read: three) projects in which people subscribed to the idea of agile methodology, I've found that all three had run into major problems. While eXtreme Programming and others promises more flexibility, speed and efficiency, I've found the opposite to be true. I've often encountered following issues:
- XP can only work if you have a team of highly self-discplined developers following all the practices meticiously.
- Seldomly do you have the customer on-site and seldomly does he speak with one voice. (Customer can also be made of a team)
- Fixed price / fixed schedule doesn't work with agile methods. In case of Scrum, the author says as much.
- Simple design and short implementation cycles generally leads to poor overall software which is difficult to maintian over a longer period of time. The only way to overcome this difficulty is by being able to continuously refactor the code - which requires CI and systematic NUnit testing.
- If you have a certain amount of team turn-over, you quickly run into difficulties if you do not have at least a certain amount of documentation. While Scrum does not say anything on that, XP claims to not need such. I've found that to be absolutely untrue.
- Offshore components are difficult to bind in.
- It does not size well.
- Longer-term projects often run into design issues, reducing speed and efficiency.
All in all, after having seen the projects fail in such a fashion, I've personally come to the conclusion that projects driven on eXtreme Programming or agile methods only don't work. Not that they don't have it right in some areas (e.g. Test-driven development is something I would subscribe to) and I can believe that certain agile methods might work, but after having seen projects fail so spectacularly, I've come to realize that such methods bear a huge amount of risk. The only situation where I might consider using such methods is when I have a software in which the requirements are unclear, the technology hasn't been tested and tried and things are time-critical. But as we all know, in such situations what results is something which needs a major overhaul earlier or later, often one which doesn't come.
While I would agree on several of the practices from XP and also agree on some things in Scrum, I would say in the whole they are incomplete, engineering focused and do not cater to the necessaties of non-developers.
|
|
|