What is involved in getting things right for your organization ? People , process and technology dimensions. How do you orchestrate your turn around and what is the role of an Enterprise Architect ?
We have many C layer people already and what the hell is the new CCOs – Chief Curator Officer. If we see our actions around what is most often do often , like share or tweet or re-tweet although doing any of the above does mean endorsement. In the information age you are counted by what you like or dislike or share or indirectly attach yourself you. It has always being like that but now it is all out in the open for all to see and in the public. You can get to know which person likes what kind of interests even before connecting up with him. It is in fact a kaleidoscope of what you stand for in the digital world. This is the reason why your online presence is very important. Be it an individual or company or an entity you need to to let people know what you all about and having a web presence makes it easy. Also you need to tell people in precise terms what this means and without any ambiguity attached to it.
Ways to earn the Chief Curator Officer title
1. Start a blog of your chosen field of interest.
2. Create your web presence on facebook, youtube, twitter,pinterest,linkedin, instagram ,vine, paperli etc etc.
3. Be specific very very specific on what you do and what you or your product / solution stands for.Will help you differentiate better.
4. Remember to evangelize or story tell what you have to say in a way that appeals to your targeted audience.
5. You are judged by how many people you can influence positively and this certainly makes your job of product evangelization much easier.
Why you as a company or individual needs to earn the Chief Curator Title
If you can send you message across to your intended audience , customers , potential clients and prospective folks of your kind then learn to story tell your story that is captivating to them and gets them interested. This is actually a game changer , the one who curates more and does it well wins the attention of his/her audience. It is all the more important for you as a company to create public wikis, blogs , videos and other content that will help you create and showcase your capabilities . Now you are just a click away from winning that customer or perhaps losing it if you do not learn the art of curating information. Some companies may say they do not have a budget for creating an online presence, in fact it is like saying we do not care to build an audience. If you do not have someone listening to you and do not make the right noise then you have potentially lost in the new digital world. So go ahead curate your offerings and leverage on capabilities to build them if you not have them internally . Get people to do it for you. This will be one of the many steps that you do to get your product or solution off the ground. Do it now lest the competition gets that coveted title of CCO.
Most often organizations struggle with whether to have Architects part of projects full time or in an advisory role. Was asked this query recently in one of the training sessions for architects on what is the best practice to have architects and delivery people separate or tie them up together in the same team. Having architects in the team would mean that they step in the projects to create a template of activities , create a blue print and later on the team takes over from there . It is more like the initial hand holding by the architecture team till the maturity in the team as a whole is there for further more complex activities to take place on a firm footing. At times having a full time architect on the team from start to end is also an option without an architecture unit separately. What is the right balance here between architecture and delivery or engineering units ?We can look at some of the aspects involved in arriving at what works for your context which would mean either keeping these units as one or run them as separate functions within your organization.
Problem : Architects and Project Delivery Folks do not see eye to eye.
This is true at times because of the reason that they have different mandates and see the process of software creation / management and delivery as a separate entity. The architects want everything to be done with a view that supports strong rational and creates a scalable , flexible and extensible architecture, clean code along with a strong sense of quality of attributes and extra architecturally important aspects. Whereas delivery folks are more inclined to meet the product delivery deadlines with reasonable quality adherence to the delivery. Delivery can gravitate towards get the job done and meet the timeliness with delivery pressure. They naturally push towards time and money as influencing their decisions and not so much on practices such as clean code, re factoring , loosely coupled architecture , services/interfaces, packaging , modularity. All of this is expected to be inherent in the architecture design churned out by the architecture team. These quality attributes of the architecture such as ease of user experience, scalability , robustness, long term flexibility of the system etc are things that an architect ponders and packaging all of this in a time period is the worry of the delivery people. So as is seen these two goals although they look quite contrary are really needed to work like the wheels of a bullock cart to pull through the bulwark of the delivery machinery. If you were to measure the two teams on same parameters it would create conflicts.
With agility thrown in good measure in projects , everyone on the team is expected to be an architect more or less. But this does not really work in reality as being an architect requires specialized skills and not easy done. But with just enough design and architecture that is continually evolving they say do what derives immediate value to the project or solution. Traditionally the role of an architect is not directly focused on the delivery and more so on direct revenues. The delivery folks can claim we did the real work and hence we are more responsible for direct revenues for the company. The architect community can say we are the ones who are responsible for all the design and blueprints for you delivery folks to go ahead and execute it. Also that all of your application code runs on our backbone platform layer /infrastructure layer and hence we are ones who move the Earth. Either way this debate serves no purpose to anyone involved. This is like the heart saying I am more important than the head etc. Both need to exist for things to work.
Have come across situations in former companies where there were separate teams for the both departments and when it worked well. Also there were instances when delivery folks were seeing doing all the work and taking the credit for. This at times forced architecture folks also to say that we need to have delivery responsibility for our pieces. Anyways all said and done architecture and delivery units needs to be accountable for its operations.
Organization Maturity : It works for some companies to keep them separate
There are companies that do a good job of both Strategy at the conceptual level and also the delivery when it comes to the nuts and bolts. These companies have a strong architectural practice and have reached a certain level of maturity with regard to their people and process.
Keeping these units separate ensures that each work for their independent part contributing to the whole. This requires that the architecture folks are not burdened with delivery pressures which are unreasonable and same with delivery folks not being pushed to climb the wall whenever there is a client delivery. If things are planned well with scope for 11th hour changes and the separation of duties and roles clearly defined then each team can be a proud owner of the aha moment in the teams when their pieces fit together with the overall piece and function together as one.
Companies that have a well defined architecture function in them and know well how to articulate and see for themselves the value of keeping these two departments separate. Teams where they are misaligned can work counterproductive to the organization vision and not achieve the same results of teams in tandem.
Setup the units to work in tandem and for the organization vision and not against other.
Who reports to whom and where is the common ground for these two teams.
There are instances where an Architect’s services are used by a manager in meeting project deliverable’s. Also an Architect can leverage on the project manager to get quality deliverables by seeking the managers help in executing the project as per the plan.
Have seen both these units working alongside and reporting to the product/solution unit head or in some cases being run as part of one unified team without formal separation. Here again these are prescriptions and we can use what suits best for a given situation and the context of the company that is setting up an architectural practice. Architecture team is accountable for the architecture pieces and the engineering teams are responsible for the engineering functions. As long they work together mutually leveraging on each other’s key capabilities this will be a good working model.
Blurring the Lines : Getting all involved in the process of software delivery
Fundamentally everything that we do is ensure we run our business well and architecture is an auxiliary unit along with other units which have to work in tandem to ensure continued success of the unit as a whole. At times we can have engineering and architecture being seen as main units and each having a target to achieve . Engineering may need to ensure that the work that is churned out by the team is of the highest quality and flawless and that it ensures customer delight. For the sake of discussion lets us leave out the other sub functions such as support , QA , various PMO functions all of which go into engineering as an overall practice and keep it that way. So this being the case engineering most often gets to get a feel for how the project is rolled out as they are close to the implementation arm of the company. Of course professional services team will have a better feel for how the project is structured during rollouts. On the whole when the architecture is not closely involved with the delivery aspects unless there are some show stoppers or implementation glitches it is easy for them to be isolated from when software meets the road or goes live. It is quite natural for some units to end up working in silos and as disconnected entities. The ideal way to run them is to allow one and all to get the overall organizational big picture and get the people motivated to work towards that. This would help all people pulling in the same direction.
Running an Architecture practice as a revenue unit.
At times architecture divisions are run like Research and Development units without a direct revenue accountability. It is difficult to attach value to innovation best example is that of twitter which is estimated to market capital in billions but is yet to monetize on its key capabilities. Also the case of whatsapp where the actual revenues are not as much as what it got bought out to by Facebook. But the fact that a certain innovation or practice and potentially is of huge value and needs nurturing and careful support from the management before actual / real value starts to show up in monetary terms. As long as there is an innovation culture on the team on all fronts attaching a revenue value to architecture can be counterproductive. But you can have soft targets which enable engineering teams to combine engineering efforts coupled with architecture add-ons which then bring out enhanced product experience and a customer that is hooked onto your product or solution. Directly attaching a monetary value may not be possible as these parameters are subjective .
There are instances of companies where architecture practices are run like revenue units where they are accountable for bringing home and driving projects end to end. Here architecture teams are entrusted with the twin job of architecting and being involved in the day to day activities of the group as well. In fact Research and Development units are measured based on their thought leadership, papers published at industry seminars and traction generated , key research findings, IP monetization and how many projects were executed and how many deals clinched and what revenues benefits are there based on the research activities. So keeping the end goal in mind helps the organization to work towards one.
Solution avoid silos : Some best practices for creating good cohesion between architecture and delivery teams
a)It is therefore a good practice to have members of the architecture team and delivery units on common group mailing lists when the engineering activities are being planned from start to finish. This gives the stakeholders of both the teams to partake in the whole process of delivering software as one unit.
b)Have a common portal share point or any such mechanism where all concerned have access to know what is happening in and around the delivery units.
c) Have a common group mail list which circulates information to all stakeholders. People actionable to be specifically mentioned in the “to section” and the ones in the “cc section” it will be for your information purposes only. For example an core engineering function would have engineering member in the to list others in cc and vice versa.
d) Invite stakeholders from all concerned in the final delivery for all meeting that are of interest to all and who have a say and influence in the matter.
e) Collect review comments from people if not able to make it to the meeting directly.
f) Have a job rotation policy of people from architecture and delivery for the ones interested and look forward for an all rounded experience. People from both teams get a well rounded experience.
g) Invite customers and have members from both team hear from the customer pain points directly instead of a customer facing team informing the teams on the issues. Organize customer meet-ups and regular interactions and action on the points arrived at by prioritizing based on a timeline
h) Have and organize tech talks regularly and encourage knowledge exchange regularly between the teams.
i) Share Reward and Recognition appropriately
There have been instances where the architecture teams worked towards creation the platform and the infrastructure portions and the delivery teams get the credit for doing a good job of the delivery or brick bats for a sloppy delivery if things go wrong. The other way around architecture develops a framework and becomes quite popular and solves most customer pain points and gets rewarded. But delivery teams associated with the framework are left behind.
But by having all concerned on the same page these things can be avoided and no single team entirely gets the credit or blame for the same if things were to fall apart. There is popular thing that works most often in management which says that if you want a job well done then do it without having the credit factor to it , a job well done itself is the reward. It can be done well when there is no inclination from either teams to clamor for the credit for having done it well. At the end of the activity the team as a whole gets to howl and party this way all the key stakeholders from all team concerned gets to celebrate success.
Architecture partitioning is a concept used most enterprise architecture frameworks often to separate concerns on how you partition your architecture based on various concerns. You can have the concerns such as length,breadth, time and domain as the parameters for slicing your architecture. Recently wrote a white paper for using enterprise architecture for being used in rural governance for rolling out micro finance solution to the rural population. Let’s say the architecture has lending, savings , schemes , offers and subsidy modules as different parts to the micro finance architecture as shown in the figure below. These parts form a part of your vertical slicing. You can go ahead and partition your architecture based on the vertical slicing which includes generally functional features of your architecture. Horizontal slicing your architecture means slicing your architecture based on technical features or features that are generally non functional . But it can also mean features that cut across horizontally across your architectures features.
For the sake of discussion relating to rural governance in India let’s say Aadhaar ID being on similar lines to SSID in the US. Although there is still a lot of hue and cry on loopholes in the system on account of Aadhaar ID and the debate that it is not functional in the practical sense on many aspects. All said and done let’s put those issues behind us and say it is approved in full measure. As per the Aadhaar mandate there needs to be a case where savings account of people for whom government would roll out subsidies so rolling out such a feature would require the below steps.
These features are central to every functional features and cut across domains. So they would generally be horizontal features.
1. Linking all savings accounts of people in need of subsidies .
2. Releasing the actual subsidy to the accounts of the account holders.
3. Let’s we want bio metric authentication for accessing all functional modules that have integrated with Aadhaar ID and since this concerns across all modules it can also become a part of horizontal partitioning.
Togaf Architecture Partitioning
Courtesy : www.opengroup.org/togaf9.1
As seen in the picture above from the open group Togaf 9.1 website, it shows how architecture can be partitioned right from strategy architecture to segment architecture to capability or solution architecture. You can compartmentalize your architecture concerns into one of the following partitions. This would be the length wise partitioning . You can partition your architecture based on architecture domains(business,data,application and technical) of your architecture and that would be the breadth aspect to architecture. You can plan your architecture work based on time based iterations and that would the architecture time based iterations.
Issues with moving directly to Solution Architecture
Some companies directly get into the solution architecture phase without much investment in the enterprise architecture phase based on their needs. A mature organization is able to move seamlessly from strategy to the solution architecture without issues. The issue is if you move directly to solution architecture then you have a tendency not to abstract common pieces of work that can be useful across other engagements and you can lose out on a reference model for your architecture. It would be more like you may have to specifically tailor a solution every time there is a need for one instead of driving the changes from strategy in which case your drivers , goal and objectives are well defined for your architecture. Ideally a mature organization is one where strategy and grounds up work are in tandem and gel well. In disconnected scenarios they would in silos where strategy is not well understood by the ground force and so such organizations do not invest in strategy due to pressures of quicker delivery. As an organization you will be judged by how well you can move from strategy to solution and vice versa in the long run. There are no doubts that a strategy well executed and understood by one and all in the organization is better than having no strategy at all. This would lead to chaotic processes and finally no accountability on overall architectural pieces and their execution.
These are recommendations from standard frameworks such as Togaf use what suits your context to enable you to better manage your architecture iterations.
Architectural Partitioning on the Server Side used in many deployment scenarios.
In a typical web deployment architecture the server side components can be partitioned based on server side functionality offered. This can be factored in the design across all tiers starting from the browser end till the database. Having a modular design of course helps in big monolithic architecture , big ball of mud. So breaking up the modules on the server side helps avoid big ball of mud scenarios and also helps server side dependencies well. Instead of creating one executable or war file on the server side it can be deployed as many different war , ear files if you are coming from the J2EE side of things. Similar logic applies for .NET and other technology stacks. How do you design for modular architecture end to end is in itself needs a detailed treatment. But this is to drive home the point that architecture partitioning as a term can also be looked at for creating modular architectures among other things discussed above.
Yes the future is open and that is what open source tries to create and emphasize. The attendance at the conference was large and many developers JBOSS / java folks were present. Developers poured out in large numbers and the air raved and ranted about goodies from the JBOSS stack and how RAD ( Rapid Application Development) can be had by using these cool tools from Redhat. This was my first to a redhat conference although have interacted with them on multiple occasions especially during a porting assignment in one of my previous avatars.
This was well attended from developers , architects and from all interested in what is latest on the JBOSS stable and how best they can integrate it into their products or solutions.
Attended select sessions from speakers and here is some brief summary of what they looked like . It is important for technology decision makers and people connected at all levels to the task of producing meaningful software to be abreast of what is latest from a popular open source vendor like Redhat.
OpenShift a PAAS solution for JBOSS developers : This is meant to have a all in one software plugins on your development environment ( maven, dependencies, libraries,deployment scripts,build scripts ) all bundled on a platform which is supposed to cut down on the dirty element in the process of churning software which is that many developers put in many many hours at creating software and lost countless hours creating different setups to be able to pull software and build them effectively. There needs to be a lot done in the PAAS area and this space will have lots of interesting things over a period of time. Eventually where thing including our local eclipses and netbeans will be on the cloud.
JBOSS is being rechristened as wildfly for the application server community edition and thus differentiates the Enterprise edition. JBOSS is no longer the application server company it has many many things under its hood and therefore justifies the change in name.
Pair programmed with Bharath of bharathwrites.in. on using widlfy and how to create an application which was organized and supervised and guided from Arun Gupta and Andrew of redhat. The wifi had its share of issues and folks running around with USBs to work around the problem. Annotation will rule the world as Java 7 has more annotations and more of it. Finally you could circumvent a lot of coding using annotations. The future would be annotations the way it goes for java and probably for other JVM languages.
Some random key take aways :
1. Websockets removes the overhead of HTTP / TCP and is preferred when you need to heavy connection based message passing. This can greatly improve performance and remove the clutter from the traffic especially the header and footer going back and forth for other protocols.
2. Batch Processing is a new feature of Java EE 7 apart from websockets, which gels with what JBOSS has to provide.
3. CDI Extensions ( dependency injection ) and add on features on how you can create features needing coding using annotations. Getting used to the latest ones are an issue but soon they can do a lot with no coding. The future is also open and annotated should be stated.
4. Fine tuning case study of a telecom major in India tuned all their way across the application stack across all tiers mod_jk , native APR , web subsystems , H/W accelerators , SSL accelerators, NUMA architectures , increased / created optimum memory page sizes on the OS, used sticky sessions and replication where possible and increased performance. This reminded my own experience where every performance increase was considered a mile crossed and when every inch , every ms every byte mattered. All of this can be useful when hard pressed for increased performance. Had interacted with clients who had spent a fortune on a machine and their only concern was did not want to move to a new machine and wanted to squeeze every pie out of the existing machine.
5. A nice case study from Wipro on how messaging solved many real time problem scenarios and how the Smart Santander a project in Spain uses much of this technology with sensors and devices to solve a lot of governance problems. Apache Camel and Active MQ apart from Kafka which was used as the ESB here was used to solve these problems.
6. Attended a nice talk on Infinispan on Inmemory database. At the outset the new statement was “Memory is the new disk and disk is the new tape”. Has a lot of use with transactional and non transactional scenarios with support for the No SQL and regualar RDBMs databases. This greatly improves performance and has a lot of settings on storing data close to where it is used and fetched using a hashing technique. This gives a uniform experience to users who could log in from any of the nodes in the system and almost be guaranteed a regular fetch time instead of varying fetch times. In memory would be the way for data fetches including transactional data which does not change too much.
People walked with hoodies and cool T-shirts apart from some lucky draw events from Intel on whose machines redhat linux largely gets run from most organizations. The future is open and this will a game changer on how to package your good small and service based. As some futurists predict there will be only three movements in future publishing , content and services based on that content. We are in interesting times where products/solutions designed to deliver value in portions and do not quote an hefty price upfront. This is the new selling mantra. And this is here to stay. Everything will be a service hardware/software/infrastructure/everything you model based on this principle can be attempted. Perhaps in future there could be a central air conditioner in a flat which could bill inmates on pay as you use and avoid people owing one and having to pay the total upfront cost when all they use it in places like Bangalore during the hot months.